First off, a couple things:
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.
Packages on the Client Side Web are Pointless
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. All that matters to the browser is that 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 as a phenomenon has not generally worked out too well. We want web now. Not after Adobe or Sun is done updating the third time this week.
The Language Has What it Needs for Structure
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? The point of avoiding the global namespace isn't that anything there is bad. It's that too much stuff there is bad because you run the risk of namespace collisions or accidentally overwriting core language features.
Just Because it's Popular Doesn't Mean We're Doing it Right
Now when you see this all over a client-side web app:
//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.
But when you get to the place where it's time to just implement all of the re-usable objects and factories and maybe one or two new temporary vars might creep into that process, it's a convenience.
But There Are Implementations of JS With Packages/Modules
Keep in mind that 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 links to files as you need them knowing they'll be cached in a browser if another page needs them again. So is trying to split up the global space by doing anything other than create adapter object factories like jQuery or more traditional objects that cover a large subset of tasks in a given domain while occupying one spot in global. There's also efforts underway to actually write modules into future spec: http://wiki.ecmascript.org/doku.php?id=harmony:modules
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). And we have persistent private-equivalent properties in our objects (just define a var in the constructor and don't expose it as a property).
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.