By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, I've listed some of them.

PureScript is a tremendous language, and I'd be happy to see it more widely used, and your points about JS interop and SPA focus are true of course, but I would argue that the step for ditching FFIs are better for some of the same reasons that were listed.

I think you might be missing part of the philosophy. If you take a look at purescript-web-dom, most of the browser APIs have merely been wrapped. This saves you work and you can use it if needed, but it is encourage to use this as a foundation to build better APIs/DSLs (heck, steal them from Elm). Elm does a similar thing under the covers, and they release an often better API than the browsers, however, you can't use this intermediate representation to build alternative APIs and many times you have to wait years for anything to even pop-up in elm-explorations because nothing is satisfactory if it doesn't improve upon the browser's standard. This philosophy has its pros and cons, and while sometimes the APIs can be clunky in PureScript because it's just wrapping the browser API, I never felt straight-up blocked by a missing feature.

With Elm you can't, for example, use the browsers Intl API to get plurals, currencies, dates, etc. This is the type of thing you want to partially apply/instantiate with your locale, then use it synchronously at the view level with your model for display. You just don't have the access to do this because a proposal must be made and approved by the Elm team. It'll probably be good API, but you'll be SOL in the meantime (for possibly years). This isn't a dev cycle that works for every person, team, or project.

This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.