This is what happens when people sip from the Pierian Spring. WMI processes are on-demand. They start up only when something requests information from or otherwise interacts with the WMI. Once that is done, the WMI processes will stay in memory for a short period of time, in case there are other requests. If there are none, they will terminate on their own. All you're doing here is preventing applications from interacting with WMI properly. Maybe you don't have any that need WMI in a critical way, but whatever. If you want to needlessly cripple a component that's on-demand anyway, be my guest. As for dllhost, disabling that is truly idiotic. That's a generic COM host. It's not just for thumbnails. It just so happens that the thumbnails mechanism uses it. This has the potential for breaking a lot of things, both Microsoft and third-party. If you don't like the shell using memory and CPU cycles doing thumbnails, you should disable the feature in Group Policy (there are a whole bunch of features controlling this feature there, and you can disable it entirely). That's the correct way to do it. Another way to do it is to unregister the thumbnail-related COM object(s), but that's the wrong way to do it--though, since it doesn't involve crippling the COM host, even that is significantly better than telling someone to mess with dllhost!
Never had any issue disabling them before both on xp, vista. I do know what they used for, I'm just a minimalist when it comes to what I like running in the background. I've yet to find something that uses the COM+ features of windows so I keep both COM services disabled as well.