This can be a very long and involved path to travel down, especially if this is planned to be a multiplayer world. Personally I pursued this very goal off and on for a couple years. I spent a month here there discovering exactly why Torque seemed to choke on a world filled with geometry that the rendering code has no problem chewing up and spitting out.
I did finally find a couple solid solutions, neither of which I consider 'easy' to implement. As all things Torque, a solution for any given project is going to require taking it by the horns, wrestling it down, and beating it to submission.
The first thing you're going to find is the biggest cause of performance drop is the network ghosts. Run your mission, push 'N' and then watch your active ghost count go up when you add the statics. As it goes up, your performance goes down. This is because Torque has a client and a server active on your machine and actually ghosts client versions of the data you change in the mission.
You are correct to assume an object to hold many sub-objects can be helpful - but only to a certain degree, depending on the ultimate goal. I ended up creating a class from scratch that rendered out several mesh cubes within one object by building all the vertexBuffer data manually in engine functions. In my case the whole thing was cubes, so I could specify the grid size, had the whole she-bang using multiple indexed materials (for different faces and extended player class footstep sounds), much neighbor detection code, added EngineFunctions, Callbacks... altogether the code for that class is spread out across about 9 or so new engine files =)
On top of all of that, I hadn't mentioned the most important part: back to networking. Even in a singleplayer mission, the way that Torque is going to handle adding and removing objects from the scene is going to impact performance if you aren't careful about how you handle the ghosts. Exactly how to handle the ghosts is a huge can of worms that can be dissected in several ways( again, each solution is going to be project specific of course ). I wrote NetEvent code for my 'object of many objects' that would allow users to send and receive data only about the 'sub-object' within the main object when adding/removing blocks.
After all that's ironed out, you'll want to be considering how all of those objects are going to be ghosted / unghosted from each client depending on distance from that object. Can't stress enough how many different ways this can be approached, but more recently I've found a system similar to the existing TerrainCell or ForestCell engine code( don't quote me on exact names! ) can be extremely effective if you're willing to fight the dragon there. He's a bit scary, but a solid attempt at making custom functions that hook into those indexes could be a good solution.
About mounting, depending on how many objects are being attached to build things it could be required the mount code be extended a bit. There are resources out there on this iirc. A bit of work moreso with models and adding the proper mount0, mount1 nodes etc. I hadn't done much testing with the effect of mounted objects on ghosting and so on but it could be worth a look =) Anyhow, perhaps some information here is helpful, I wish you luck with Torque!