Wrong. Splitting logic into separate threads is not necessary. In order to make the engine independent from FPS, you have to decide, how to handle excess/missing output. You can buffer, transform, average or simply drop excess frames. Missing frames can be worked around by repeating previous frames or reducing effective resolution (often done with a bit of blur — hi, Nvidia!). In either case there are limits to what can be achieved with those workarounds — eventually you'd have to throttle the fastest producer (renderer, physics engine or player input). All of that can be done just fine without threads — using asynchronous programming (incidentally, this is why many advanced rendering APIs are asynchronous).
Most games can simply "drop frames", when renderer isn't up to speed with engine. The result is minor loss of visual fidelity, which usually isn't too bad, unless FPS are horribly low. Things are more tricky for terminals, because 1) they need to maintain scrollback history 2) their output is more blocky, so "dropping frames" leads to horribly-looking ASCII animations.
There are some terminals, that do start dropping output, when rendered can't keep up. Others (for example, xterm) do refuse to do that by default, because they assume, that underlying program may do better job at handling low framerate, than general-purpose terminal emulator.
Either way, if you want to achieve fluid, visually pleasing rendering, you renderer should be as fast as possible.