You mean, Unity is built around the concepts of object-oriented programming? Amazing insight. The point is, debugging a complex game with a physics engine isn't always as simple as "make one change to the one main script and everything that uses that script works perfectly again".
If it really, actually was that easy, Facepunch Studios would have the game ready for a 1.0 release already.
This game shouldn't be that complex, compared to other games this is really really basic stuff. The hardest issue they should be having with multiplayer is Syncing and even than somehow this manages to screw with your HTTP horribly. Also the Physics Engine is more than likely Unity's itself otherwise it's "rumored" to be Havok Physics Engine or Source Physics Engine.
Also @Pallaptink response is beautiful at responding to this man.
Have you ever been involved with a major software project? I am guessing not.
If 1 mechanic can build a car engine in 10 hours, can 36,000 mechanics build that same car engine in 1 second?
No.
There is clearly a number between 1 and 36,000 that is the optimal number of mechanics, and it is closer to 1 than 36,000.
You cannot just throw more money at a project to speed it up. It can certainly help, but the factors that determine the speed, quality and quantity produced are a lot more complicated than that.
This is me and what every normal person would think a ideal dev team would consist of;
Main Directors/Planners - 1
Coders - 2(Could be 3 depends on how in-sync they are with each other)
Graphic Designers - 3 (Most optimal for pushing out updates for Graphics... I'm looking for things like tree graphic, better bitmap detail, etc if possible)
Sound - 1 (Everyone needs at-least one sound guy)