I would separate your post into two things: One is the idea that declarative interfaces can be faster, and the other is that Apple is dedicated to fast interfaces.
The former, as you are seeing from several other posters, is not a new thing, and is in my opinion a history of continual and significant failure. It is so consistent that I now have an almost visceral revulsion to people singing me the song about how wonderful "declarative" can be, which is sort of ironic because they intend the opposite. Calling something "declarative" is one of the strongest signals that a technology is going to be a pain in the ass to use. (In fact I'm sitting here racking my brains for a stronger one and I'm not sure I can come up with one. "Enterprise-ready" perhaps? Maybe "Hosted by the Apache project", which often indicates a quality project but one that is definitely going to be a real pain.)
The real reason this will go fast is that Apple is prioritizing speed.
I also was concerned about your comment above "developers mostly express the "how" – put this control at these coordinates etc." So far as I know, that is a strawman; no modern UI toolkit works that way. The web has had a major influence on them and every major toolkit has a more web-like layout available (and I am collapsing history here for simplicity, I am aware that relative layouts were available before the web, but the web definitely made them all step it up another notch, further consolidated by interface diversity between touch & mouse & screen sizes). If anyone using a major modern toolkit is dropping text at a particular coordinate, that's on them using the toolkit incorrectly, the toolkit has long since stopped forcing that.
What the toolkit needs in order to do what you're talking about is basically the DOM for the thing it is displaying right now (for whatever the toolkit calls that concept). It is not particularly a problem for the toolkit if that DOM is built by imperative code or by some 'declaration'. It probably will end up supporting both anyhow, because how the DOM tree gets built isn't the important part. Basically identically to how a browser functions, it doesn't matter to the browser (as a UI renderer) whether the DOM it is working with was built "imperatively" or "declaratively" or "reactively" or "purely functionally" or anything else; the DOM has what the browser UI needs to render quickly, and to the extent it has troubles rendering quickly, the solution is more information in the DOM for the browser to chew on and use in its decisions, not a rewrite in how the DOM is generated. Declarativeness is entirely irrelevant here, in some sense because regardless of how you get there, the DOM-equivalent is already by its nature guaranteed to be "declarative".