I believe that, rather than a CPU usage limit (which would require some kind of CPU-cycle accounting tracking, which would impose a high overhead on a system that's based on high-level source-code interpretation rather than on a bytecode virtual machine), the PICO-8 chose instead to go the route of limiting code complexity by just limiting (Lua source) code size. So your code can go as fast as you like — you just can't have very much of it. Which seems to result in practice in games that have similar features and play-styles to retro-games, despite the constraint coming from a different direction.

Like I said: fantasy-console abstract machines don't aim for technical limitations; but rather, for stylistic limitations. They don't want to impose upon you low-level technical barriers, for you to just treat those limitations as implementation-time programming puzzles to be overcome or worked around. (If you want that, just write games for an actual retro console!) Rather, they want to impose high-level constraints that influence your design-time choices. Less like typing on a broken keyboard; more like writing a poem with constrained rhyme-scheme and meter.

That's why these are "fantasy" consoles — their particular lack of technical constraints means that they can actually require a decent modern CPU/GPU/etc to run; and so could never have actually existed in the era they borrow their aesthetics from.