If you've ever worked in a large environment, where the numbers of nodes number in the thousands, or tens of thousands, then you know many software packages don't scale to that size very well. I've seen quite a few pieces of software that were well written, and ran well with hundreds of items, but choked miserably when the count crept past a few thousand. Typically those are edge-case sized installations, and most applications aren't designed for, or tested at, those scales. I haven't registered 1,000 instances in SSMS, but I could guess that it would not necessarily run smoothly with that many instances being examined.

Software designed at scale tends to take the "install another central node" and manage multiple central nodes individually. That quickly becomes a pain point for the humans that administer the systems as they must learn and remember where individual systems are being managed. It's not much different for hardware as well. When a system exceeds the capacity of a single node, we often find that we are adding multiple modes and managing them individually. Many backup systems work this way, adding new units to handle the additional backup space requirements.

However there's a staffing cost as well, and it's one that can be overlooked as a company grows. More systems mean more backups, more maintenance, and more failures. Even with automation and standardization, there's a physical workload increase on your staff, and also a stress level increase from managing more systems. It can be easy to overwhelm your staff, assuming they can easily handle the additional load because they have plenty of tools to do so.

Tools are required, and whether you build or buy them, you'll make use of them if you want to minimize your salary costs. However you still need to make sure you grow your staff, train them, and give them time off. The last thing you want is to overload and burn out a small staff of one or two. I'd bet that the week your staff quits or takes ill, your systems will choose to fail.