When do you really need an organizational unit in Active Directory?

In general OUs are used for:

• Keeping things clean and structured. Your users are kept away from groups, your groups are kept away from computers, objects in site A are kept away from objects in site B, and so on.

• Delegation of control. Only really needed if you have multiple levels of access or multiple sites with different admins in each. Even so I would plan ahead and set things up to enable it anyway.

• Group policies. Not totally necessary as policy application can be managed via either permissions or WMI filters, but all the same it helps to know that if a user is in OU X they get policy Y.

Note that in the above you cannot apply a GPO to a container, so if you don't create OUs you will have to set all of your GPOs at top (Domain) level and filter them using either WMI or security. It's easier for you and for everyone else to just use OUs except for if you have a scenario where the specific policies you want/need cannot be done (or can be done but are messy) using an OU model.

Aside from the obvious technical requirements in my last 2 points, I think that keeping things clean and tidy is reason enough. It's easier to find the object you want out of a list of 100 than it is to find it out of a list of 1500, for example. It also separates the objects you create (users, computers and groups, mostly) from builtin objects, which can help to prevent nasty accidents ("OK, who deleted the Administrator account?").

OUs are used to organise objects in Active Directory. A typical example would be as follows:

myDomain.loc
├─Users
├─Servers
│ ├Domain Controllers
│ └Member Servers
└─Workstations
  ├New York
  ├London
  └Brisbane

This makes it easier to differentiate objects in the domain visually, rather than having to rely on memory or digging around. Using this structure you can also apply policies to specific containers. You could have a general Internet Explorer policy applied to the Workstations OU so it applies to all child objects in that tree. You can then set specific Internet Explorer settings to the sub-OUs (for example, different policies that set the IE Home Page for London workstations, another than sets a different homepage for the new York workstations etc.)

In your specific example it seems you want to delegate AD control to a group of users. In this case the right method is to create a new security group and make all the target users a member of that group. Then, you would open AD Users and Computers, right click on the OU you want the users/group to have control over, and select Delegate Control.

Now... if you organise your AD properly, you can have granular control over what you want that group of users to have control over. For example, you could create a group called NewYork-Admins, and delegate control for that group JUST to the New York workstations, instead of all workstations.

An ideal AD structure for this type of delegation would be a structure as silimar to the following:

myDomain.loc
├─Domain Controllers
├─Special Users
└─Locations
  ├─New York
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  ├─London
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  └─Brisbane
    ├─Users
    ├─Workstations
    ├─Servers
    ├─Contacts
    ├─Servers
    └─Groups

This allows you to delegate control to AD objects in a very granular way.