3DRad had 3 boundaries.

The first boundary is the number of objects that can be used in a game. This becomes a problem when a game maker tried to use too many of these objects to make games that only uses these objects. The objects are fun, but they limit what can be made with a game.

The second boundary is the amount of processing that you can get out of a single script. An interpreted script is not as fast a compile c++ program for example, and can't process as much in 1/60th of a second. The scripted approach does however increase what can be made by only objects to about a factor of 100. So with scripting you can make games that are not possible with objects alone.

The third boundary is laziness. This is when game makers don't really explore what is possible with the game machine, and just accept their defeat without experimenting with all available options.  Guys like Mike and fourdee have proved that if you persevere, you can set your own boundaries and discover where the boundaries of the 3D Rad really are, anyone else is just lazy and giving up without a lot of serious experimentation and investigation.

This is not intended as an insult to anyone, it is simply a fact.

A whole city of a 100 cars in traffic is actually possible in script. One has to use imposters with their own steering AI. It is not a simple task, but it is very doable. Traffic behavior programming is an old technique which has been used in many games, and was even applied in the very first 2D Police Quest game from Sierra. Most of the logic and program code is available free on the internet, if one is willing to go the extra mile.