Unintentional and easy to explain.
NES couldn't do parallax scrolling on it's own, it had to use a mapper for the task, so the implementation was cluttered (as can be seen onscreen, actually; with the pattern glitching on borders). On top of that, NES didn't have an internal clock (a feature no console had until Saturn and 64DD came around) so you were running a counter in software to track time, competing for the same resources as the rest of the game.
Running would put incredible stress over the software so the clock would slow down accordingly, it just didn't slow the whole game down deliberadly in the same manner, because they were most likely painfully aware of it (and instead of trying to sync it they opted to give priority to the game/gameplay fluidity instead).
A software clock without a crystal oscillator is never accurate anyway.
Actually, the NES could do parallax scrolling on its own without a mapper. There is a built in method for doing one split, but you can also simply (hah!) use some precise timing of your instructions and split the screens as many times as you want. It's easiest with a mapper that includes a timer, true.
The built in method is called sprite 0 hit. You pick the location where you want the split to occur, and put sprite 0 at that point, which usually contains just a small horizontal line to be sure the hardware detects a collision there. When the screen is being drawn and it gets to that point, it interrupts the drawing and gives you an instant to modify the screen scroll, so you can make the areas above and below sprite 0 scroll at different speeds. This is most often used for a status bar, so part of the screen doesn't scroll and that info stays right where it is.
However, you don't have to have a background status bar - some games (Mega Man, Castlevania 2) do their status (just a life bar) with sprites. These games could take advantage of their simple interface to use sprite 0 hit for parallax scrolling, and in fact later Mega Man games did this.
Mario 3 does use sprite 0 hit, you can see the horizontal line used for it in some emulators.
I believe Mario 1 uses the bottom line of the coin icon at the top to do this. It doesn't require a mapper.
You may have meant to say the NES couldn't do sidescrolling without a mapper, but that's also not true. You can do regular scrolling fine without one. In fact that's what the artifacts at the side show us, that it's using the normal method of scrolling. When stuff scrolls off the left side of the screen, it scrolls back in on the right, so you very quickly alter those tiles to what should be coming up next.
The NES has two virtual "screens" (pages) that can be aligned horizontally or vertically. If you line them up horizontally, there's a whole screen worth of data not being seen, off to the left and right. This gives you ample time to change the graphics on those pages while they're not visible. However, this means that if you scroll vertically, it's going to wrap those graphics around immediately, ground up in the sky, so you have to quickly change those and will see some weird graphics at the edges.
Mario 3 does the opposite. The two pages in memory are stacked on top of each other vertically, so horizontal scrolling requires quick graphics modification, but not vertical scrolling. And you'll notice that most Mario 3 levels are exactly 2 screens tall, perfect for the 2 vertical pages in memory!
None of that requires a mapper. The mapper is more for being able to address more memory for more graphics.
Oh also, running a counter is actually trivial...incrementing a variable, even a 16 bit one, takes up so few resources as to be negligible.
I haven't examined Mario 3's source so I can't say why the timer is delayed, I just wouldn't assume it's due to resource usage.
They're nowhere near the degree of hardware mastering of SMB3, and you can't possibly run as fast through a level on Super Mario Bros 1. And I don't recall Super Mario Bros 2 having a timer at all, if it did the same thing would probably occur, as it shared the same MMC3 chip as Super Mario Bros 2 did.
Something's gotta give.
Actually this was just discussed and tested on June 16.
You can move exactly as fast in Mario 1 as in Mario 3, that is, 4 pixels per frame. Any faster than that and you get glitches (though the game still runs).
In both Mario 1 and 3, walk speed is 1.5 pixels per frame and run speed is 2.5 pixels per frame. In Mario 3 when you are running as fast as possible with the P-meter, you're going 3.5 pixels per frame...but Mario 1 also supports this speed just fine!
Mario 1 is actually
more thorough when drawing the screen, as it fixes those glitches from going too fast, but in Mario 3 they remain on the screen.
.png)