"Cars vibrating" is a physics bug that only happens if the processor isn't capable of running the game smoothly (graphics card calculates graphics faster than processor does on physics, thus not synchronized), or too low FPS. If you somehow manage to make this game run at very low FPS you'll see all cars simply try to fly, or vibrating with very weird physics. The lower the FPS, the more they'll vibrate. But it can happen on very high FPS too, depending on the game.¹
A computer with a very good graphics card and a Pentium D, for example, may run this game at 90fps and still have the cars vibrating at many times. Sometimes the game may even ignore collisions with other cars and walls: you just get through it like it doesn't exist, even with high FPS.
Here's a video I recorded on my PC now using fraps with FPS limited to 10. It demonstrates perfectly what I'm saying above and shows all of the most common bugs² that may appear. http://www.youtube.com/watch?v=ik92SaVFdIcVideo is now available on Youtube.
Note: this exact same bug also happens on most, if not all of Simbin games. All you need is a not good enough processor or low fps (about 20~25fps). And it happens to Crysis too when using default settings. But FPS has to be a lot lower on Crysis: about 6~8fps for a good processor (if you limit the FPS, of course), or about 30fps (not limited) with a terrible processor. If you start running with speed mode on rough terrain, you'll randomly die because your legs got through the ground or because you made it through something else. But it can be fixed on Crysis by using a console command that synchronizes it. sys_physics_CPU 0. The default value is 1, where physics have an independent framerate.
¹Physics have an independent framerate, so amount of lag depends on CPU. Most of Simbin games, rFactor, Crash Time 2's engine (includes Ferrari Virtual Race), Crysis and some other game uses independent framerate for physics.
Benefits of using independent framerate for physics: FPS almost always stay at higher values. ²Side effects: lag depends on the processor, and very weird bugs may occur, such as ignoring collisions (other cars, walls or anything else, including the ground), vibrating, graphics and physics not synchronized, excessive grip on racing games (thus causing car to suddenly flip on a turn), etc.
This command doesn't increase FPS at all, it just synchronizes the physics and graphics to run together. It's more likely to make you have "lower FPS", but it'll surely make it a lot more playable if the person is having physics bugs in the first place. Again I'll choose Pentium D as a example: imagine a PC with a amazing graphics card but a old processor trying to run Crysis. This PC will run it a lot better with sys_physics_cpu 0 because it'll synchronize frames. It'll make you have lower framerates, but it'll be really a lot better and without any bugs.
Yet the PC on the example above: sys_physics_cpu 1 = explode a house with a grenade and props will fly in slow motion. Get about two explosions at the same time and you'll feel like you're playing a first person shooter on a online game server with 999 ping, because the character will take some time to respond to your commands and will very often skip a few meters depending on how much lag you've got, plus it can get through things and instantly kill yourself in a ridiculous way (such as getting through a car and making it explode with the force of your body just by walking on it lol ).
Another example of a bug that may appear is when throwing heavy objects: when they hit something, instead of breaking that thing (e.g.: a wall, wood barriers or something), the object will suddenly stop and fall delicately. sys_physics_cpu 0 = everything is going to be synchronized, no slow motion, and no single-player character or physics lag, although a bit lower FPS.
Just look at the first 40 seconds of this video and you'll know what I mean: http://www.youtube.com/watch?v=VaHS-y_mapQ
0:16 - very smooth water (graphics), very laggy boxes (physics). Since water is running much more smooth than physics, resulting FPS will be higher.
0:36 - water and boxes synchronized. "Lower FPS", but much more playable on low-end processors.
Important note: this video was rendered, which means it isn't real time gameplay. That's why there are thousands of boxes in there. The synchronized one takes a lot less time to render and the result is also much better. But that's exactly the same thing that happens on real time gameplay, except that you won't have 30fps with 3 thousand boxes.
But remember, this is for low-end processors. It will only help for mid/high-end processors if you're having any weird physics bug (which is very unlikely).