Another way of looking at JavaScript is the 1 million and 1 things you can do with the function as a construct.

That jQuery plug-in authoring thing is awful. I have no idea why they're advocating that. $ extensions should be general-use stuff that $ already has pretty-well covered not build-me-a-complete-widget methods. It's a DOM-API normalization tool. It's use is best buried inside your own objects. I don't see the appeal of using it as a full-on UI library repository.

What I don't personally like about packages on the client-side web is that we'd basically be pretending we're doing something that we're really not. In a post .NET webforms and gobs-of-horrifying-stuff-that-never-panned-out-from-our-Java-friends world, I'd rather think of a hunk of HTML with linked resources as what it really is and not try to appease learning-new-things-resistant OS app developers by pretending it's something else. In JS on the client-side web, nothing gets "imported" barring doing something awful with Ajax that operates in ignorance of browser-caching, which yes, many have tried to do. It was either loaded in and interpreted or it wasn't. We don't have more code stashed on the client somewhere available for use "just in case" for good reasons. #1 being that I just described a plug-in and browser plug-in dependencies for web apps suck.

JS objects are highly mutable. We can have branching trees of namespaces to any degree that we find it useful to do so and it's very easy to do. But yes, for anything re-usable you do have to stick the root of any library at the global space. All dependencies are linked and loaded at the same time anyway, so what's the point of doing anything else?

Now when you see this everywhere:

 (function(){
 //lots of functions defined and fired and statement code here
 })()

The problem isn't that we lack tools to structure an app around, the problem is that people aren't valuing structure. For 2-3 page one-off temporary throwaway sites at a design agency, I don't really have a problem with that. Where it gets ugly is when you have to build something maintainable and legible and easy to modify.

And keep in mind, in Node.js, where such things make a lot more sense, they do have modules. JS, assuming we can avoid uber-config-hell that plagues other languages, is the only thing in the equation and each executed file is its own isolated scope. But on a web page, linking a js-file is itself the import statement. Doing more imports on the fly is just a waste of time and resources since getting the resources requires a lot more effort than simply adding files as you need them and knowing they'll be cached in a browser. So is trying to split up the global space by doing anything other than create object factories like jQuery or more traditional objects that cover a large subset of tasks in a given domain.

So no, there's nothing wrong with auto-invokers used to avoid global namespace pollution when there's a good reason to use such things (more often than not there isn't). The fact that we CAN do such things, however, is awesome. Heavy usage is a sign that JS developers are still maturing perhaps, but it's not a gaping hole in the language to anybody who's not trying to force a paradigm into the client-side web that just doesn't make sense here.