There are many different variables that come into play regarding this. If two faces are next to each other that use different textures, light levels, colors, etc.. you more than likely won't be able to join them together anyhow (nearly anything's possible with enough work, but it'd probably be FAR too much work).
If, however, you have a lot of cube faces with the same textures, light levels, and colors, it's totally possible and could make a huge difference in your performance.
My engine, which may be completely different than yours, keeps all like faces segregated into different arrays. By this, I mean for a chunk (32x128x32), all visible faces that are on the tops of all the cubes are in their own array and the same for the north faces, the west faces, the bottom faces, etc. With this, I can easily cull entire chunks from being passed to the render stage or I can simply skip sending all west faces from a chunk that the player is east of.
With that in mind and understanding that joining neighboring cube faces requires nearly identical data on each of them, if you set up a good way to keep your arrays sorted and "walk" over the array properly, it's completely possible to improve performance. Whether or not you want to go through all the work to find out is up to you though.
I don't think anyone can actually answer the question of SHOULD you do this except you. Without knowing how you store your data, how often you have situations that even let you join faces, etc.. I don't think anyone can truly answer.
If you want to look into it though, I'd suggest going the shader route described here. That's the way I'd suggest doing the actual joining. To join them, however, I suggest the way I describe in this post at the end. It's easy, while not 100% optimal, it is quite fast.
