1. KI's differ from project to project, but basically come down to 3 things. Bandwidth and Capacity of either processors, non-volatile storage or network infrastructure. Whilst the latter would be bringing things outside of the scope of unified computing (besides the limitations of single system servers as far as networking performance), keeping growth manageable has always been about having a big cache pool and larger bandwidth, as well as keeping 3x failovers (in addition to tape backup etc), so that in periods of extreme unforeseen demand, you have a large pool of cache that should soak up the missing bandwidth and you can cannibalize one of the failovers to provide 50% more storage (as half of the storage has to act as a failover to the new data).
I don't work on absolutely mission critical systems though. Lots of the data I store is very low demand. I work on unified webservers in a university that also double as virtualisation hosts, entry access and frontline account dataservers (there are secondaries that run through peak hours as well as tertiaries that run during updates etc). Rather than run servers for each task, I now run all as all but with the critical account data on a separate low power server. Power efficiency is much better thanks to the fact that I can disable and even shut down all but two systems per rack during off peak hours and have the others on network startup with a response time of around 10 seconds. (I have one on standby for a 2 second resume and the rest fully shut down)
2. Yes, we do. The answer to that simply is to requisition the biggest, densest parts now and leave slots, racks and connectivity to spare. If we need 50TB of space, we need at least 2.5TB SSD cache and we have a SAS capacity of 25 sockets, we get 4TB HDDs, but we only half fill all our storage racks. Parallel SSDs obviously increase bandwidth so that is on a per case basis but the 120% rule applies. We have no intention of doubling our storage needs this year, but storage racks are cheap, RAID will always justify it's cost provided we get one's with good throughput and downtime for installation of storage racks are not. Our primary servers use 16GB RAM sticks in a 128GB configuration, because again, only a quarter of total needs is sated. We want the hardware not only to be able to handle massive growth in users, for example if there is a news article about the Uni that drives a spike in traffic, but also a massive growth in the needs of the virtualized machine demands. Of course when DDR4 comes out, like DDR3 was, it will not be cost effective to move to straight away and we will review the servers then.
3. IMO you should always have a off-site cloud service like AWS for emergencies, but only as a last ditch "fan+poo" solution. This is not my job in my workplace however so I probably cannot help you with anything up-to-the-minute.
4. Yes, yes and more yes. But not always. Most of the tasks that an aisle would carry out are a particular resource intensive. For us Virtualisation is storage intensive, web-service and database is granularly CPU intensive (due to DB's strong crypto) so can be distributed well over spare CPU capacity but is storage bandwidth and capacity intensive, so what we did is separate our systems into two 'silos' for 4 (technically 3) tasks. The databases themselves are on their own aisle, but the processing is on another. It would have been possible to completely consolidate the two into a 'super aisle' of sorts, and probably saved a system or two worth of unused cycles and bits in the process but security makes it impractical to partition away the protected data, and simpler to secure that data further on a physical level.
5. I would say reliability and running costs as well as investment. The fact that our load balancing and redundancy now scales across nearly every system we have due to the fact that most are dual or triple purposed, means that a worst case cascade failure like a power regulator failing and causing a blowout (god forbid) does not always mean too much downtime as we can now fire up previously single purpose failovers or backups and have them carry out all of the jobs. This in turn means we need less backup systems, and we can run less systems at lowest-demand hours as our idle power draw is much lower across the board.