I'm equally repulsed by huge, highly nested functions. However, I'd have to say that the game play provided by this function was one of my favorite parts of Jedi Outcast.
The nesting is too deep imho, but apart from that it looks ok. This looks more like a design problem, because there are lots of special cases, but the code style is ok.
That function is almost 1500 lines long, full of complex nested if conditions and commented out blocks. I understand how code (especially game character control code) grows to become like that, and I've probably been guilty of some similar horrors myself, but the most I can do with such code style is excuse it.
Sometimes the program logic consists of hundreds of cases and putting it all into one function is a good solution, since you see the complexity.
I know that object-oriented best practice would suggest a lot of different classes and using dynamic dispatch for switching. That might even be faster. However, I dislike the fact that this scatters the logic across hundreds of files.
The best solution would be to simplify the logic, but this is also the most costly/time consuming variant.
I was also surprised to see these huge functions with multiple nested layers. Is it common for game development? Or it was just a quick hack on top of Quake engine?
Yes, it's very common in player / vehicle controller code.
People start with a clean model of how the player should move, using minimal physics, then add layer upon layer of special case code for various environmental / state / networking edge-cases.
It's usually what makes the game actually feel good to play.
I've heard looking at the first person movement code for Valve's games will make you wish for your own death, but stripping out the weird stuff which looks ideologically wrong just makes the game play worse.