1. Once your project reaches a certain size, you have no choice but to start using strange naming conventions to avoid name collisions. Packages, at least from what I've seen for decently sized projects, solve this problem.
While Python's flexibility with functions/packages is nice, I'd argue on the client, you tend to have a lot more code, especially once you start using something like Dart.
2. Libraries. Talk to +Cliff Hall
, or read some of his posts on here. The whole naming prefix, etc. just doesn't scale, and is a burden on the developer to learn. It's worse in team environments, especially if someone fails to enforce it.
Example, would you rather learn this:http://developer.anscamobile.com/resources/apis
(open class list on top left):http://getmoai.com/docs/
It's also called "f'ing stupid" just in case you were curious.
When distrubiting code, there are 3 things you're concerned about.
A) ensuring it works, without muss/fuss in any project, configurations, etc. Drop the code in, import it, go to town.
B) you can copy pasta the code w/o worrying about folders. On PC this is easy, on Mac, it's a manual process. Either way, with Java packages, it's easy to organize this ( at the beginning of a project anyway ).
C) Branding. Having your name/company/project embedded in the package name itself is huge. For example, most Flash Developers worth their salt know Greensock merely from the package name.
Object models are one thing (like Ext JS's recent switch from 3 to 4 to abandon prototype and ensure they don't pollute it + support multiple app instances on the same page).
However, actual files + libs are huge here.
On multi-team projects, you need to organize code. Whether this is MVC/MVP/MVVM/YourMom, at a framework level is a large swath of folders.
Secondly, types of View's. When doing GUI work, you tend to have a steady growth of GUI code; forms, components, item renderers, util classes, etc. These are also segregated out into sections, and sometimes entire teams just remain there.
Third, this segregation helps architects and build masters do manual diffing and testing.
For some libraries, they need to hide certain packages; whether from the IDE, the developer, and/or the runtime. These are usually like helper/final/private functions, classes, etc. that all live in a private package. The vendor can thus keep their public API the same, but change their internal application within a team environment using the above.
I abhor this practice, but understand people need it, so....
1. Large project code organization
2. Libraries: usage & deployment
3. Segregation: team focus & easier diffing/source control/team management
4. Privacy: <-- dumb, but people will buy it