A bit of clarification: When you say "HDMA allows Mode 7 to do cool tricks that it couldn't do on its own", technically, the only thing that Mode 7 *can* do on its own is an affine transformation: Translation, rotation, scaling, and skew. It can't actually do perspective transformation without HDMA changing the matrix registers on each line. HDMA is actually what most games use to change the mode itself since the mode register is one that it can access. Super Mario Kart is one example of a game that does manipulate the registers in the middle of the game using the CPU: In split-screen mode, it turns on forced blanking in the middle of the frame, then loads new sprites for the bottom half. This takes a few scanlines to complete, which is why there's a thick black bar separating the views. All of the other effects, including mode switching and perspective are done using HDMA.
For the Mega Drive, there's actually a specific benefit to performing DMAs during VBLANK. The VDP performs DMA ~10x faster while the screen is disabled, which is most commonly the case during VBLANK.
An interesting point about sprite flicker (at least on the Sega Master System, though I assume on most 8-bit onsole at least) : Sprite flicker is not an automatic process. On the SMS, sprites have different priorities, based on their location in the Sprite Attribute Table (SAT). Those with a lower address on the table, ie. $3F00 will be given draw priority over those with a higher address on the table, ie. $3FFF. So if there are 9 sprites on a single scanline on the Master System, only the first 8 sprites with the lowest SAT address will be drawn. The rest will actually be completely invisible. Sprite Flicker as we know it is actually something that has to be coded in by the programmer. This is usually done by shuffling around the addresses of each sprite in the SAT so that their priority is constantly shifting. This is viewed as flicker by the player. You can see this happening if you open up an SMS game in an emulator like Emulicious. I believe this is also how the Game Boy Color works, but the original black and white Game Boy determines the draw priority by which sprites have the lowest X coordinate, so I'm not sure how flicker would work on an old-school DMG Game Boy, or if it was possible. I'm not very familiar with the DMG library unfortunately. Interestingly, slowdown is ALSO something that doesn't happen automatically, and must be manually coded in by the programmer.
Also worth noting how V-blank came in different sizes per platform for hardware performance sake, why DOS gaming was 320x200 and Genesis was 320x224, or how few platforms actually were 320x240 or 240p in the 90s till much later in the decade. Same for the 4:3 anamorphic stretch varying too, which was a pain in the ass with cross platform development lol. I tend to only refer to "background tiles" and instead say "sprite blocks" just to make sure there is no confusion between both units rather than say "tiles" for everything in statements.😉
There's a demo out there where someone actually shows the SNES displaying seven out of the eight available backgrounds modes all running on-screen at once just by switching them down the screen. It's a fugly programmer art demo, but it's pretty technically impressive and shows some of the potential there.