These people call an app "static" when all content is dynamically generated at runtime on the client-side. Everybody else calls these things "single-page web applications". I really don't see the point of defining a new, confusing term for an existing concept.
Actually, we built our static hosting service because we were already developing with a static web architecture and couldn't find an existing acceptable option for hosting.
I'm building the platform because I believe in the technology, not espousing the technology because I built the platform. :)
I also believe in the technology and the general architecture you're espousing. I found the content on http://www.staticapps.org well written and constructive and the links to http://www.divshot.com are unobtrusive.
My reaction to http://www.divshot.com is something else entirely. To solve the "problem" of static file hosting and deployment with a service that is "compatible with Angular and Firebase" and supports "pushState with custom routes" is clearly disingenuous.
Not that there's anything wrong with effective marketing. If your target audience is people who don't know what the words mean, then knock yourself out.
We're trying to market to people who want to use static architecture, regardless of experience. It's a bit of an education issue as people are familiar with e.g. Angular and Ember but don't necessarily know what it means to deploy them as a static app.
Can you tell me what you find disingenuous about the claims? What would appeal to you when describing a static web hosting service?
