There are a couple of reasons we want to provide a separate distribution mechanism:
The first reason is that we really do care about users getting a consistent out-of-the-box experience with GNOME 3. We want to be judged on the experience we designed, for good or bad. But in the end, we know that some users, and especially the sort of enthusiastic customizers who read LWN will have other ideas about what works best for them. With extensions we want to give users the chance to go ahead and deeply modify their desktop in all sorts of ways, but we're not so crazy about distributions and OEM's doing the same and presenting the result as GNOME without the user even knowing what been done. extensions.gnome.org is a purely user-focused approach to finding and installing extensions.
The second reason is that extensions are not working with a stable API, so have very specific version requirements that don't really fit into the normal assumptions packaging systems make. If a packaged extension says it works with GNOME Shell 3.2 only and not with GNOME Shell 3.4, then that will likely break the user's attempt to upgrade to the next version of their distribution. We'd rather just disable the extension and let the user find a new version when it becomes available.
But to me, probably the most important reason is simply that we can do better. If someone packages the C library, or Apache, there's a large amount of work to be done to make things work correctly with the system. But at the level where a GNOME Shell extension works, every GNOME version 3.2.1 system looks just about every other GNOME version 3.2.1 system. So why should users have to wait for someone to wrap up an extension in an RPM or DEB in order to use it? Why should an important bug fix be blocked on the same process? Why shouldn't you be able to see the comments and reviews that all users have on an extension?