I read today the article of Dan Holme on delegating powershell access (click here for the article) and shared somehow his dissapointment. Briefly, in order to be delegated this role, the user must be a Site Collection Administrator (not just a site owner, member or visitor!) and have a db_owner role for the Content SQL database for that site collection. (SharePoint_Shell_Access role is nested into the db_owner role on the SQL side).
Definitely this is quite a very important barrier for rights delegation in Sharepoint and especially Powershell. Imagine that site owners/members could have used Powershell to script and automate some of their recurent tasks (site or content privisioning/update). But in this tiny detail, I see the importance of a good and comprehensive analysis of user needs at the very begining of a SharePoint implementation project. Product owners or Sharepoint architects might consider this in their planned architecture.
So be aware: If you already know or at least you anticipate that you might be called by your users to delegate them this role or to let them automate some recurrent tasks on the future Sharepoint 2010 farm, THINK now of building site collections instead of a tree of sites in the same site collection.
As it was said during a session on architecture at the Sharepoint Conference last year, site collections remain in SharePoint 2010 an important boundary and this not only because of the size of the content database and backup considerations. Now we have this access delegation which is extremely important in a corporate environment.