Because it's easier to programm a single thread that executes a sequence of commands like [ update-gamelogic, update-graphics, etc. ] instead of at least 2 threads (for gamelogic and graphics) that you have to synchronize somehow. Synchronization can be pretty difficult!
Tying game logic to the framerate doesn’t really have anything to do with single- vs multi-threading. You can properly calculate the time since the last update in a single-threaded engine.
If the game loop doesn't run at the same speed as the render loop you'll get 'tearing' - some game objects are at the latest state, some are not.
That can cause some funky bugs.
From my understanding, tearing can occur even if the game logic and render command submission happen on a single thread, since it’s a consequence of the OS compositor sending buffers to the monitor in the middle of rendering.
correct, but now you've just identified two separate types of tearing, both happening at different times. put them together and the perceived frequency will be significantly worse than it was prior.
being able to zero one of those out and only worry about the other means you can hopefully optimize a better solution - as much as one can when you can't realistically atomically update the entire display from top to bottom.
Tying game logic to the framerate doesn’t really have anything to do with single- vs multi-threading. You can properly calculate the time since the last update in a single-threaded engine.