Why would you want to? Your whole environment will be down when the machine, or some component thereof, fails or is rotated out for maintenance
I think this is more of a benefit for cloud providers in that they can pack more disparate customer workloads on to a single machine.
The advantage of such a machine is that if it starts to die, you fail over everything atomically and then repair/replace the backup. You don't need to think about what happens if one component is on a dead machine and the others aren't (does your load balancer handle that well, given machines often "die" in ways that just make them slow rather than totally failed?)
The big win though is if you get rid of the microservices and run the whole thing in one big process. No complex RPC failures, obscure HTTP/REST attacks like https://portswigger.net/blog/http-desync-attacks-request-smu... and so on.
That might sound mad but modern JVMs can run lots of languages fast, and have ultra-low-pause GCs that can use terabytes of heap. Like less than one msec low. Many, many businesses fit into these really high end machines with a giant JVM.
I've written about the possibility of a swing back to big iron design here:
https://blog.plan99.net/vertical-architecture-734495f129c4
And a look at modern Java GCs - GC being historically the bottleneck to really large single processes:
https://blog.plan99.net/modern-garbage-collection-part-2-1c8...