I'll start with the short version: Sprite 0 and HUDs at the bottom aren't a very good fit for each other.
Longer: The NES' Picture Processing Unit (its graphics processor) renders pixels from left to right, top to bottom while the CPU runs in parallel. As you've probably learned from the video, when an opaque pixel of sprite 0 overlaps an opaque pixel of the background, the PPU sets a bit the CPU can detect, so the scroll position can be changed in the middle of a frame. However, due to the order the PPU renders in, the further down the screen this occurs, the longer the CPU has to wait. And while the CPU is waiting, it can't really do much else. (Like run logic for the gameplay.) So the lower down your HUD is, the less time you have for gameplay. That probably explains the lag.
Some cartridge types allow for detecting the PPU at a specific point in a way that doesn't require waiting, so lower HUDs would not steal time from gameplay. Mapper 30 does not have anything like this. There's another way to do something similar to what you get on cartridges that can detect what the PPU is doing, but I've never fully understood how it works enough to actually do it.
Changing what the PPU is doing mid screen usually requires really, really specific timing. There are four writes to change the scroll midscreen (at least, in the super fine way), and the last two must fall in a very specific time period in between rendering horizontal rows of pixels. (The horizontal blank, or hblank period.) If they don't, lots of weird stuff can happen. (Flashes.) And you may wonder how the writes could be mistimed only sometimes if the sprite 0 hits at the same time every time. The answer is because the PPU runs faster than the CPU, and margins between the bit getting set and the CPU actually being able to recognize it are finicky. NES Maker may not actually do the four write version, but still midscreen PPU updates are usually finicky business.