The player may move in either direction. You can do one additional and then just throw the margin onto the side that you're moving toward when you start scrolling, but it's easier to just do it on both sides and tile-based engines are pretty lightweight in the rendering department.
I think the first time I did it I actually had a 1-tile margin that I would just move around to the other side of the screen, like using logs to roll a boulder on, lol. I'd scroll the tile sprites and then when a row/column passed out of the screen I'd move those tiles to the other side of the tileset. It got pretty crazy for a while until I refactored it and did it right.
Edit - I guess I should be more clear about what I'm talking about.
If you use a single-tile margin then when scrolling triggers to the left you should 'snap' the tile sprites such that the current extreme-right tile is on the rightmost edge and the 'margin' (offscreen) column is on the leftmost edge, then move all the tile sprites smoothly to the right for the length of one tile. Then you 'snap' again and repeat as needed. However, if you scroll to the right you have to snap oppositely - such that the leftmost visible tiles are placed in the leftmost edge of your tile sprites and the margin column is offscreen to the right, etc.
Using a double-width margin means that you can have a margin in all 4 directions. This way you can skip the first step (the snapping to one side or the other) and just start smooth motion of the sprites, then just reset the sprite positions and snap the tiles to center when you finish scrolling by 1 tile.
It sounds trivial, and it kind of is, but in practice it makes the process less complicated by removing that first snap.