Based on a quick look at various Phabricator tickets and other information it appears to me that the only connection between the WDQS and Wikidata edit throttling is that a slowness parameter for the WDQS is used to modify a Wikidata parameter that is supposed to be checked by bots before they make edits. Further, it appears that the only reason for this connection is to slow down Wikidata edits so that the WDQS can keep up - the WDQS does not feed back into Wikidata edits, even edits by bots. So this connection could be severed by a trivial change to Wikidata and the only effect would be that the WDQS KB might lag behind Wikidata, either temporarily or permanently, and queries to the WDQS might become slow or even impossible without improvements to the WDQS infrastructure. I thus view it misleading to state in this Phabricator ticket that "performance issues [of the WDQS] cause edits on wikidata to be throttled", which gives the impression that the WDQS forms a part of the Wikidata editing process or some other essential part of Wikidata itself.

I was completely unaware that WDQS is so integrated into the inner workings of Wikidata. Where is this described? Was this mentioned in the announcement of the proposed change?

If 'unskolemizing' is a trivial step then that should be implemented by WDQS, instead of pushing it to every consumer (including indirect consumers) of Wikidata information, if this change is simply a change to make WDQS work faster.

In T244341#6113236, @Lucas_Werkmeister_WMDE wrote:

The difference is not with other SPARQL queries in the WDQS but against SPARQL queries in general (including SPARQL queries that use Wikidata URLs).

Is anyone proposing a change to Wikibase (or Wikidata)?

If divergence between Wikidata and WDQS is bad, then this proposed change has another bad feature as it turns the some value snaks into something that is less like an existential. And this proposed change is for both the RDF dump and the WDQS.
And then there is the problem of the proposed change requiring changes to SPARQL queries - not just a change, but a change from how SPARQL queries are writtern in just about any other context.

My view is that fewer breaking changes are to be preferred, and breaking changes in fewer "products" is to be even more preferred. So, again, I wonder why there is a breaking change proposed for the RDF dump instead of no breaking changes or limiting breaking changes to the WDQS only.

I don't understand why it was considered necessary to make a breaking change the RDF dump to improve WDQS performance when there is a solution that does not make a breaking change to the dump.

I added some technical content on this issue to https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Query_Service_and_search#Blank_node_deprecation_in_WDQS_&_Wikibase_RDF_model

What's happening to finish this task? P2559 has about 1790 uses, which is not an insignificant number, but P2559 is insignificant because it isn't prominently shown.

Of course it would by a breaking change. There is no formal spec of the JSON dump beyond the spec for the individual entities, but we have always said that the dump is a set (an array) of entities. Putting something in there that is not an entity will break consumers.

Right now, the JSON dump format is a sequence of JSON objects. Each of these JSON objects is a Wikidata entity. There is nothing preventing the dump format from having the first JSON object be information about the dump, including version of the dump format, version of wikidata format, time of dump, etc.