I think the world needs to better understand what differentiates a webapp from a website, because internet users are directly affected by that difference every single day.  Is Twitter.com a web app? Yes.  Is this website a web app?  No.  Is Gmail a web app? That one is debatable, but yes.  

What even defines an online resource as being an "app" instead of a "site"?  I think the most definitive answer is that web apps transfer presentation separately from data, and do not employ a strict request- response technique for doing so.

Your users called, they want their time back.

Users care about speed, functionality (therein usefulness) and ease-of use.  As developers, we can draw rather direct parallels to the technical aspects of web development from these general requirements.  For speed, and since this is the web, we're talking almost exclusively about speed of data transfer (requests take much longer to transfer than to execute on the server).  Functionality is created by selecting the most effective set of features for an application (more is not always better).  Ease-of-use is important in webapps because we are still collectively helping computer users to adopt a new way of thinking about applications - if a user's first web-based application experience is horrible, they will most likely avoid using web-based software in the future.

So.. why classify "apps" and "sites" based on what the data looks like?

Users care about speed, and we know speed is most affected by data transfer time, so that's where we can draw a clear line between the "old" and "new" approaches.  A website transfers data and formatting via a single request, which is optimal when loading new pages is the primary means of retrieving new data.  A webapp transfers formatting and presentation information as part of an initial download process, much like downloading a desktop application.  Once this information has been stored, data is then downloaded in a serialized format - optimized for speed in a situation where page loads don't occur. Examining the data being transfered makes it easy to determine which paradigm something is optimized for. Simply look to sites like Facebook and Twitter, where you can see an evolution in the direction of "webapp" for no reason other than to provide a better experience to users.

Doesn't that mean everything should be an app?

You're not getting the point - that would be premature optimization at its finest.  If you are establishing a web presence for a business, where your needs are little more than an online business card or simple e-commerce site, don't build an app.  Your time would be better spent working with the client to optimize their site for Search Engines or creating PPC landing pages.  However, it would certainly be beneficial to apply lessons learned from the world of webapps to your website - things like HTML5's ApplicationCache and AJAX history can go a long way to improve user experience.  A general rule-of-thumb is this:  if your project is web-based, data- driven and is its own product, a webapp would be a wise choice.

So, there you have it.  Apps, both web and native, have an initial download followed by speedy data transfer.  Sites throw everything into a pile and download formatting intermixed with data.