If you want to phrase it in programming terms, there's a pretty obvious comparison to semaphores and deadlocks. We've deadlocked. As a workaround we've increased a bunch of our semaphore limits. But we also had those limits for a reason (various balances of safety, efficiency, and available amount of other ancillary resources). Maybe now we'll run out of some other resource, or hit contention somewhere else - we don't really know, the system is big and hasn't been operated in this state before. And on top of that, we didn't solve the fundamental deadlock - if the underlying conditions persist, there's hard limits to how often we can do this before we deadlock permanently.

No, it isn't a leak as the containers are empty but not garbage. It is very common to allocate extra memory that isn't used - in garbage collected languages you often need to fight the garbage collector for maximum performance in specific ways - which means you will have empty objects just waiting to be filled. You will get around to them eventually, but for now they are just taking up memory. If you allocate more of these objects than you have physical ram you will start swapping - but there is no leak, you will eventually either use them, or destroy them.

If you don't worth in latency senstive applications you might not have encountered a situation where you need to apply the above tricks.