If your world's user concurrency remains high a sufficient amount of time then the sim hosting it will get an entire Large Amazon EC2 instance all to itself. Those types of servers are multi-core and have 7.5GB of memory. They host the sim(s) containing the world(s) and some additional services, while the grid services are located on our control servers and the assets themselves are stored in Amazon's S3 cloud storage (with multiple cache levels on our other servers). This means that a lot of the load that your existing dedicated server needs to deal with is distributed to other servers when you use our solution. Given what you described you should be fine adding more prims but I'd recommend minimizing texture usage as rezzing textures can make viewers slow down to a crawl (nothing to do with Kitely, just the reality of how the viewers work).
One thing worth noting is that the viewers people use can have a very big effect on your server load. Specifically, using v3 viewers will allow using HTTP textures instead of UDP ones, thus enabling your sim to offload texture delivery to our Apache servers instead of delivering them to viewers directly (this is part of Kitely's cloud-based asset service optimizations). v1 viewers, unfortunately, don't properly support HTTP redirection which prevents this optimization from working thus forcing the sim to handle texture transfer via UDP, which creates a drain on both RAM and CPU.
You can see all the info that is delivered by OpenSim to your viewer but you don't get admin access to the server running the sim your world is using.