I sure was guilty of big sites just as much as the next guy. It just saddens me that insted of promoting what we've learned it the past years and applying to current projects we're doomed to repeat bad UX from before.
Sure. Maybe it's literally always a Bad Thing to show a loading screen. But plenty of apps have made that choice, for some reason or other. Maybe the developers are incompetent, or maybe they have a combination of technical and resource constraints that make this the best choice for them. It doesn't matter. At least this loading page can improve users' experiences with apps that have, for whatever reason, made the choice to go this route.
If you look at web applications, Google's music app ("My Music" in Google Play) uses a load screen (complete with progress bar) because it's seriously bloated, while Amazon's Cloudplayer just loads and does its thing (which is, playing music).
Needing a load screen is a sign that your app is not, or aims at not being, a Web app anymore - in the sense that you'd also want to loosen the other restrictions - give it its own window, possibly have local file storage or FS caching, etc.; In that case, something like TideSDK ( http://www.tidesdk.org/ ) may come in handy to deliver a desktop app to power users that is based on the same codebase. And, maybe you'd still want a web app that is functional and lean. (As an example for two apps with non-identical possibilities, Google's My Music allows you to change song metadata on desktop browsers but not in the Android app - yet another sign that My Music is meant as a desktop-y app).
In many cases it can be a sign of hubris or lazyness that you cannot get rid of the bloat. Be real and think whether your users actually enjoy waiting that time, since they'll be doing it more often, on machines with less resources and/or slower connection, than yours.
