Here's the line you read (or hear) when it comes to targeting a workflow (i.e. discovery, rule, monitor, etc.):

You cannot target a group directly, you always need to target a class like Windows Computer, disable the workflow, create an override afterwards to enable the workflow for a limited number of instances (Windows Computers in this case).

So, what's all about targets (classes) and groups?

A group (after you created one) is basically a class, very much alike the "Windows Computer" class. The main difference is, it's a singleton class (only one instance will always exist) and it is hosted on the RMS (which is maintaining the group membership). Because of this fact, you:

• see all the groups in your system when you have to choose a target class
• see every workflow targeted directly to a group's class run on the RMS (this is the host of the singleton-instance) because OpsMgr thinks that's the place you want to execute the workflow.

A group can have members (nothing more than instances of other classes) from different kinds. You can actually have one or more "Windows Computer" classes and one or more "IIS Web Sites" class instances mixed with some "Logical Disk" class instances, all in the same group. 
 

Why do we need to specify a target which is not a group when we create a workflow?

The most obvious reason is the "Variable Replacement Mechanism" (I have no clue if there's an official name for that). When you target a workflow, OpsMgr knows all attributes (properties) of your target. This allows you to pass any attribute from the current instance your workflow is running against to your workflow. For example, when you target a workflow (i.e. a script monitor) to the class "IIS Web Site", you can pass the attribute "LogFileDirectory" to your script.

After you select the target you can access all the attributes from that target in your workflow:

This is one of the most powerful features OpsMgr has to offer in all the workflow processing. Once you've wrapped your brain around that concept you will realize that this beast can do almost everything in a relatively simple way.

As a result, the following rules apply:

• Once you chose a target class, you cannot change it after the workflow was applied to the system. This is simply because of the implications related to the "Variable Replacement Mechanism". When you change the target, all the dynamic values you pull in might or might not work afterwards. I guess the engineers at MS could come up with a solution allowing you to change the target and prompt for each and every dynamic value to change for the new target class but as you can see for yourself, the outcome is unpredictable. Therefore they just disabled the option to change the target class. Even doing so in XML can be a mess and you often just end up creating this workflow from scratch using your new target class.
• Because of groups can have members of different classes, there's no way for OpsMgr to find out which attributes can be used for the variable replacement. Consider our previously shown group containing classes of "IIS Web Site", "Logical Disk" and "Windows Computer". Each class have a different set of attributes, so targeting a group directly would prevent you from using the replacement feature. Many of the built-in workflows and vendor MPs depend on that feature!

But why can I target a group in the Windows Service monitoring template wizard?

Since OpsMgr 2007 R2 the Windows Service monitoring template wizard was “upgraded” and allows you to specify a group you want to target the monitor. I really wished they designed that dialog differently because every new user will get confused because all the workflows are not directly targeted to the group you specify in this dialog!

In the end, the wizard is doing the exact same thing behind the scenes you would do when you create your own workflow:

It creates a disabled workflow (in this special case a discovery) targeted to "Windows Computer". 
 

It then creates an override for this workflow, enabling it for the group you chose. 

Ok, I need to do overrides, any other benefits of using this technique?

Using an override to enable/disable a workflow for a group of members has also its advantages. See Jakub's post here:http://blogs.msdn.com/jakuboleksy/archive/2006/12/06/overrides-in-scom-2007.aspx

Jakub explains how overrides are actually applied and shows how powerful this mechanism really is. In short, for overrides it isn't really necessary to use the exact same target as your workflow is targeted to. The calculation algorithm allows you to be more flexible here. For example:

A workflow targeted to an "IIS Web Site" instance can be overridden using a group containing "Windows Computer" instances. OpsMgr will find out for which "IIS Web Site" instances this override will be applied and includes all instances running on the specified "Windows Computer" instances.

Summary:

I completely understand anyone having a hard time with this concept. It is a bit strange at first and as most of you I had to get used to it as well. The stuff above is just a very condensed view and is far from being complete. There are several other reasons, benefits and rules in the workflow engine I did not mention here. These are the facts that helped me to understand the engine and platform better and I hope I could illustrate some of that for you.

One thing MS can and should do better is making these concepts more accessible in the UI. It begins with the very confusing terminology in all the dialogs and wizards and surely ends in the documentation. The documentation is getting better and better while the UI is still confusing or getting more confusing (see Windows Service monitoring template wizard).