I agree that effects that don't affect the actual game logic won't necessarily need to be framerate independent. Something like interpolating between two camera positions, for example, may not need it. But consider this example:

An explosion happens right in front of the player, filling the screen with large particles. Even though they're simple, there's a lot of overdraw, and older machines can be quite significantly affected by such circumstances, even though the explosion might have no effect on the framerate when viewed from far away. The explosion might normally only last a second, but if framerate drops to a third of what it normally is the explosion will last for 3 seconds if it doesn't take advantage of time_step, when the player really just wants the explosion out of their face ASAP.

That's kind of an exaggerated example, I admit. And here's a counterexample: I recently changed the rate at which particles are created during a drift/burnout to be framerate dependent, because if someone's framerate is dropping below 60, it's probably a good thing if less particles are being created. So I guess it depends on exactly what you're dealing with. But with good use of time_step, you should have no problems with settting your fps_max higher than what you normally achieve on your own PC.

And perhaps you need to look into some optimisation, but I imagine that's a much bigger task in your project than in mine

Jibb