It's more splitting the scrolling routine across several frames.
For example, I have a side scrolling game which uses 32x32 metatiles. The scrolling area is 6 metatiles high. The scrolling routine is the split accross four frames: first frame I decode the map data to a buffer, extracting the 6 metatile indexes, reading the attribute bytes from a LUT indexed by metatile index, and putting them into VRAM. frames 2, 3 and 4 I draw two metatiles each. This means that once a new backdround column is needed, the engine takes 4 frames to draw it.
Doing it that way, the routine is so light that I can place it before the sprite 0 hit I use for the screen split. As scrolling speed is never > 8 (not even > 4) pixels per frame, and I'm using vertical mirroring, by the time the new column enters the screen and is visible it is 100% drawn.
Depending on the game, the scrolling direction(s), the metatile size, etc. I use several approaches but, in the end, I always split the action accross several frames. Time is tight. I could do all the scrolling in 1 frame, but that frame would have a sudden CPU peak.
As for developing in C, I guess it has to do with your mindset or maybe with what you are used to. You can get pretty low level in C, which is also a plus, and you can always rewrite a couple of routines in assembly if you need
My games are not very complex. At the end of the day, it is whatever floats your boat, or whatever makes the experience more enjoyable for you