In reply to mark k..

It is very annoying for core contributors always to respond to criticism with an attitude of “we know better/you don’t know what you are talking about” :(

It's not my intention to respond with a sense of superiority. If that's how my comments read, then I am sorry. You're asking good questions. But also understand that we spend countless hours architecting, discussing, debating, and engineering solutions such as selective refresh. So many of the questions you're raising have already been considered and accounted for in the design.

The selective refresh violates DRY for anything that requires a JS code, and shouldn’t everybody write JS instead of php now?

Selective refresh is specifically designed to eliminate the need to write special JS in the vast majority of cases. Normally to register a new selective refresh area should should only have to do a single $wp_customize->selective_refresh->add_partial() call in a customize_register hook. The need to introduce additional JS to support the partial being selectively refreshed is needed only when JS is involved in the rendering of the partial.

Full page refresh is the KISS and DRY way, and the problem of it being so slow need to be fixed, and it should be triggered only when needed (user change the name of the site, he has a long text, why is there a need to refresh before he finishes typing it?). […] it is that there are architectural problems that are being ignored in favor of working on the next shiny thing

Selective refresh necessitated by WordPress's PHP-centric rendering of templates. A slow refresh of the preview, while architecturally DRY and KISS, presents a horrible user experience. The only way we'll be able to make a theme 100% DRY and KISS is if the theme is built using JavaScript, where changes to the customizer settings are synced into the corresponding JS models in the preview. A theme built using React would do well here in the customizer, and this is something that the changes in 4.7 are specifically designed to facilitate. I've also worked on a proof of concept that exposes REST API resources in the customizer and directly syncs changes into Backbone models in the preview: if changes to the models then trigger re-rendering of views (as they should) then this is also an example of a KISS/DRY selective refresh in the customizer. You can read more about this in my post Bridging the Customizer and the WP REST API.

We're also overdue to chat about selective refresh and JavaScript in #core-customize on WP Slack. Let's try to do that this week. Cheers.