As someone who runs a Wordpress-powered non-blog site outside of the wordpress.com cloud, here is my experience of the JS and release cycle issues:

In the old/current release model, disruptive (or even harmful) changes are arbitrarily bundled with bug-fix releases, the moment e.g. 4.6 came out, no further bugfixes were made for 4.5-based sites. As cleaning up and adapting to disruptive changes takes time, this prevents timely deployment of bugfixes. I would much rather see something like the Linux kernel model, where some "LTS" major releases get a steady stream of bugfixes long after later majors are released, with a healthy overlap between the release of a new LTS and the end of bugfixes for the previous LTS (during which time, sites and plugins can migrate to the new LTS at their own pace).

As for JS, JSON, XML-RPC and other APIs for app-based editors, I find those to be among the disruptive/dangerous/harmful elements that I strip out. Security-wise, I don't want to expose unused and unknown APIs to random attackers. And privacy-wise, I don't want to expose my users to logging or other stuff from random 3rd parties such as wp.org, gravatar.com, so each element from such sites needs to be removed or replaced by a local copy. Neither of these security measures are made particularly easy by the current WordPress code and release cycle, as I often have to trawl through the pages and files to find and fix these one by one. Like having to add extra PHP code to remove the new emoji-mapping scripts that load images from an external site in 4.6 . Restricting wp-admin and equivalent access to specific ways of accessing the web server required even more invasive work, and seems especially badly affected by the constant adding of new features.

In short, every new or old feature needs an effective and easy off-switch. Anything that is loaded implicitly from 3rd party sites needs an easy way to switch it to local hosting.