Determining the correct settings for your Virtual machines can be a pain with any hypervisor, but even more so with something like ProxMox that gives you tons of options. I do most of my work through SPICE on ProxMox virtual machines and have learned some things along the way.
One thing I see people get tripped up on all the time is how vCPU allocation works. Most people I have talked to believe that allocating a vCPU to a host locks a thread of your physical CPU to that virtual machine. This is not the case. Instead what is happening is that a process is created for each virtual machine, and just like any other process, it will only consume resources when needed. This means you can over allocate vCPU cores to your virtual machines how ever you need to as long as the total processing load is something your system can handle.
Most of my virual machines are running single socket, quad core processors. I chose those numbers semi-arbitrarily bearing in mind the expectations of modern operating systems. Modern hypervisors are really good about conserving resources and allocating processes without a ton of overhead as long as you stay within the realm of sanity for your allocations.
Changing the vCPU sockets/cores only really changes what the guest sees is available for use. Your CPU is still going to handle the work essentially the same way regardless of virtual allocation. That being said, each allocation of a vCPU does incur a bit of overhead which can scale poorly if you are allocating absurd amounts of resources to your VMs. For most home labs, I would recommend sticking to 1 virtual CPU socket and 2-4 cores. This will give the virtual CPU enough threads to work with to efficiently handle multiple processes at a time without too much overhead. The only thing to bear in mind is that some servers, especially if you are getting into the realm of running a SIEM, will expect more CPU cores to be available due to parallel processing demands.
Memory allocation works in a very similar way. Your virtual machines get an allocation which they are not able to exceed; however, they will only consume what they are currently using. This means that you can allocate more memory across your virtual machines than what you have available on the host if you expect them to hit peak utilization at different times. This works well for jump boxes if you only plan to use one of them at a time. The only thing to be cognizant of is memory caching. If you have a bunch of virtual machines that have large memory allocations that are all caching a ton of data thinking they have plenty of memory to spare, you will end up needlessly overloading your system. I would recommend 1-4GB for servers and 8GB for workstations as a baseline. You should scale that based on expected utilization as necessary.
Getting into the quality of life improvements, ProxMox offers a ton of options for remote displays. Sticking with the default NoVNC shell is fine for anything that doesn’t have a graphical interface or for machines you don’t use very often; however, you’ll want to switch to SPICE if you want to use the VMs as remote workstations. I have had the best experience with VirtIO-GPU and 256MB of memory. This comfortably streams a 2K ultra-wide display. Allocating anything over this would be overkill unless you are running software which requires more GPU processing. If that is the case, you should consider PCI passthrough and a decent physical GPU.