...

Add to Favorites is added to the per-portlet options menu:

Configuration

Turning it off

If a user doesn't have a folder of type "favorites" in their layout, the theme transform detects that fact and suppresses "Add to favorites" from the portlet options menu, since there's no folder into which to save the user's favorites.  This means that you can control who has access to Favorites by deciding to whom you direct DLM managed fragments with folders of type=favorites.  

If you publish the Favorites portlet and the folder of type=favorites to no one, then you can safely ignore the Favorites feature entirely.

You might gently introduce Favorites to a beta audience by only publishing the Favorites portlet to that audience and also only publishing favorites-type-folder-containing-fragments to that beta audience.

Integration with Marketplace

The Marketplace portlet is intended to be a good place for users to browse for favorites.  If you choose to implement Marketplace (or to substitute your own suitable portlet), you can tell Favorites the fname of your Marketplace portlet via portal.properties configuration.  When this fname is declared, Favorites will display the link to Marketplace in appropriate places.  When it's not declared, no worries, degrades gracefully.

Forced favorites, restrictions on re-ordering

Since individual favorites and favorited collections are merely usages of DLM layouts, DLM edit restriction apply. Because these types are goofy, the built-in admin UI tooling for editing these layouts and the restrictions on them just doesn't work.  However, you can edit the DLM fragments containing the template type=favorites and type=favorites_collection folders by editing and importing/exporting the relevant fragment-layout XML entity files.

Delete restrictions should just work.

Re-order restrictions will be goofy, since the Favorites edit UI currently only makes a partial effort to reflect DLM restrictions.  If it thinks you can't move an item at all, the move control is suppressed.  However, DLM is more complicated than that – conceivably you might be able to move an item to some drop locations but not others.  The UI won't reflect this and experimentation suggests that rules would only be enforced on next login.

Anyway, those ordering restrictions seem like false requirements.  If you actually have those requirements, please do get in touch and/or jump in to help implement support for them – our own feelings at Wisconsin are that we probably want to leave re-ordering wide open for end-user customization if they care enough to re-order.

Who's interested in adopting / working on this?

...