Glad to hear that this solution isn't that uncommon. :)

I'm currently running my racing physics at 600Hz, so <2ms of added interpolation latency.

That's a lot. o.O

I'm curios now: what are the "common" tickrates used for games? (I know that this will depend heavily on the genre and gametype and has to be determined individually for each game.)

Given that the this approach requires the CPU to be fast enough in order to process X amount of ticks per second (otherwise we would have a CPU bottleneck and the game would slow down) you need to make sure that every operation (physics, collission detection, AI, etc...) can be crammed into 1/600 of a second in order to run properly (at the desired speed), am i right? (Such a high tickrate wouldn't cope well with open world games which have way to much random variables influencing the load on the CPU?)

If your tickrate is 60fps then you don't even need interpolation on most monitors. Just present the latest state of your simulation on each vsync, bingo. You can use interpolation to support higher refresh rates, and then being one frame behind at 120hz and up really isn't a big deal.

It's worth remembering that a 600Hz update doesn't necessarily have to be "for each object, update everything about it, and repeat 600 times in a second". It can be something more like, "put all your physics stuff in vectors, then perform 600 vectorised operations that each simulate 1/600th of a second". You might not be able to do that for the entirety of your updates, but perhaps for more of it than you think.

And obviously if one game can easily handle 100 actors at 60Hz, it makes sense that some other game can handle 10 actors at 600Hz. In fact the latter case is probably faster because there are fewer potential interactions to consider (and because the smaller amounts of data make it more cache friendly).