EDirectory Design Guidelines
A: Time to throw out the magic catch-all answer: It Depends :) . I'll give you a quick history of why each style exists, and you can make your own choice.
Any method "works", the primary goal of tree design is to make sure that, if you ever have to partition it, the cross-partition traffic (especially across WANs) is as minimalized as possible. A secondary goal is to make sure that rights inheritance (if you assign rights to a higher level OU, they trickle down to all objects below it) is as simple as possible.
Because of these reasons, trees were originally layered on top of the business' organizational structure with the WAN design at the very top, hence the ou=location,o=corp.
With the advent of the Internet, DNS became arguably one of the most successful distributed databases ever. Since DNS is a form of directory, people started modeling their trees after their DNS layout, since it was often partitioned by organizational site as well to ensure proper zone file distribution (accounting.ny.mycompany.com, sales.dc.mycompany.com, etc.), so it made sense to layer it on top of that, since all the design work was already done for DNS. Microsoft Active Directory, for all its faults, does the DNS-based design layout quite well, and their DNS server is even integrated to build a DNS layout based on the tree structure (saving a lot of work) and they are what popularized the newer dc=mycompany,dc=com method.
So, back at the original question, your goals are to minimize WAN traffic and ensure easy rights flow.
The general rule of thumb (which BTW is a horrible saying if you know it's origin, heh) Is to do the organization method if your company isn't really aligned around the internet (i.e. you make widgets or sell paper), and the DNS method if your company is ecommerce based (i.e. you run a web site or provide financial transactions services to companies, for instance).
If you are a small organization, the vast majority of design decisions don't matter at all, since you'll probably just have a single partition with multiple replicas, and partitioning isn't an issue at all. However, for enterprises with hundreds of thousands of objects, these issues matter a great deal.
Here's a few articles with some good information as well: