Don't forget the third way in which contacts can 'belong' to an organization: CiviMembership. This raises again the issue of the lack of clarity in the concepts of Relationships versus Memberships (as I've discussed in Forums and briefly at CiviCamp), and I would assert again that a better approach would be to merge the concepts, making Memberships either a subset of Relationships or a sub-set of Groups, rather than a separate entity.

From a user perspective, Organizations as Groups fits better with the exiting permissioning system. This is not necessarily a strength, as the existing permissioning system is relatively incomprehensible for many users, so a drastic re-design would likely be an improvement. Organizations as Organizations (per option two) does seem more intuitive at first glance.

I am very much in favor of abstracting the idea of 'groups' so that any set of contacts can be treated as a 'group.' (Therefore, available to CiviMail, Permissioning, Searching, etc.) It does seem the idea of 'everything as a smart group' is a way to accomplish this, though the scalability question is key. Every Relationship definition, Membership definition, Tag, etc, could have a corresponding Group.

In combination with Group<->Role sync, this opens some powerful possibilities for Drupal integration. For example, all Employees of OrganizationX could receive automatic access to a private Forum, or any given Drupal feature.

One factor in making option two widely useful will be adding improving the ability to create relationships on import. Currently, there does not appear to be a way in the UI to attach imported contacts to a selected pre-exisiting related contact, although a new contact and relationship can be created via imported data. I'd like to see something like the current 'Add contacts to Tag/Group' feature for relationships.