My work-from-home workstation always has a VM or two running the test/dev environment for the tasks I’m working on at work. They are VBox instances provisioned/managed by Vagrant.
They are CentOS7 instances, each running a test database, usually a text editor, “tail -F” monitoring log output, and various daemons/services specific to my workplace’s internal infrastructure. The host system is running Slackware 15.0.
On one hand, I think VMs are overused, introduce undue complexity, and reduce visibility.
On the other hand, the problem you’re citing doesn’t actually exist (at least not on Linux, dunno about Windows). A VM can use all of the host’s memory and processing power if the other VMs on the system aren’t using them. An operating system will balance resource utilization across multiple VMs the same as it does across processes to maximize the performance of each.
Docker and Kubernetes are popular mostly because the industry has broadly given up on release engineering. This means applications/services can have different and conflicting dependencies, so the only way they can run on the same physical host is by putting each in their own containers or VM instances, each with their specific dependencies.
The alternative is to have a platform with standard libraries, and to port applications to the platform, using the platform’s libraries as their dependencies, and thus avoid conflict. This requires effort and discipline, so of course it is not very popular, though it was the standard practice twenty years ago.
As far as I know the only Linux distribution which still follows the platform approach is Slackware. Applications which are ported to Slackware are guaranteed to work well together without conflicts, but not a lot of applications have been thus ported (Slackware only has about two thousand official packages, in all).