I've noticed that a lot of companies use "reverse domain name" namespaces and I'm curious where that practice originated and why it continues. Does it merely continue because of rote practice, or is there an outstanding architecture concept I might be missing here?

Also note questions such as: https://stackoverflow.com/questions/189209/do-you-really-use-your-reverse-domain-for-package-naming-in-java that sort of answer my question but not 100%

(If it makes you feel any better, I'm really curious if I should be using it for my javascript namespacing efforts, but I'm more curious about then when and why, and that should help guide me on the javascript answer, nota bene: "window")

Example of this practice extending to folders and files: 

Reverse Domain Notation has its origins in Java, but is widely used in many platforms, such as Android Packages, Mac OS X Packages, JavaScript, ActionScript, and more.

The practice is extremely useful because it provides a decentralized system for namespacing software. There is no need to apply to a centralized agency for a namespace; simply use the domain name you own (reversed) and manage that within your own organization. By naming packages like this, one can be almost certain that code won't conflict with other packages.

From Oracle's Java Tutorials:


  Companies use their reversed Internet domain name to begin their package names
  for example, com.example.mypackage for a package named mypackage created by a 
  programmer at example.com.
  
  Name collisions that occur within a single company need to be handled by
  convention within that company, perhaps by including the region or the
  project name after the company name (for example,
  com.example.region.mypackage).


It's more than a rote practice, it's good practice because it's a complete and fully specific namespace. If there were two companies named Acme and both chose the namespace acme., their code would conflict. But only one of those companies can own the domain acme.com, so they get to use the com.acme. namespace.

Reversing the domain name allows for a top-down architecture. com would contain code for companies (or anyone who owns own a .com domain name), and underneath that would company (domain) names. Then, deeper within that would be the structure of the organization and/or the actual namespace. (For example, if it was code from a network called internal.acme.com, that gives this department their own sub-namespace of com.acme.) This top-down structure is used in a number of applications, including in systems administration. (It's similar to reverse IP address lookups.)

Personally, I use it for all new JavaScript code I write for my company. It ensures that the code will never conflict with any other code, even if I later write the same code for another company. It can make accessing the code cumbersome (typing com.digitalfruition. can get a bit much) but that can easily be worked around with a closure and a local variable (var DF = com.digitalfruition).
