LÖVE

Aaron, I think you too worried with this. LOVE engine do very well his job working the old fashion with tiled maps and reprint over and over just only is saw on screen. You don't really need spritebatchs to deal with tilemaps unless you have technical reasons to stage in that way the graphic scenario. Probably 95% or more games using tile map stuff were done using conventional map drawing methods and no one seems to complain of having performance problems, And it's safe. The question is do you really need to starting "buffering" map graphics? Do your tile maps need use framebuffer and risk that your game work in another computers?

Another "common" technique would be using a SpriteBatch about the size of the screen, and every time you move, you'll update that SpriteBatch.

Option B like the fist of an angry god. Just make sure you store your tile map in a quick-to-traverse format. My game Underlife uses this approach to draw so many tiles so fast, it's like magic. Basically, store your map in form of map[x][y] = tile. Then, you traverse it with numeric for loops when drawing. With a tiny bit of simple math, you can know the range of tiles which are drawn, which you use as your start and end numbers in the loops - draw culling for free. Plus, it makes things like tile physics easier.

Lord knows I've described this system half a dozen times around here, I should make a wiki page on the approach...