I see no basis for these assumptions.
Not really an assumption when Apple says that is what they are doing.
"... Srouji’s team found itself interacting regularly with other departments, from software programmers, who wanted chip support for new features, to Ive’s industrial designers, who wanted help making the phones flatter and sleeker. An engineer who sat in on Srouji’s meetings remembers senior managers preparing extensively for presentations, because his support was critical for getting new features approved ... "
www.bloomberg.com
The industrial design team digs "holes" that the silicon team is suppose to get the product out of. That is why Apple's broader use of the processors design for getting out of those particular product "holes" is typically as a "hand me down" processor that is already 'paid for' in terms of R&D and just has more than enough "horsepower" for that broader product placement.
" ... “We've got our own custom-designed performance controller that lets you use all eight at the same time,” Shimpi told Ars. “And so when you're running these heavily-threaded workloads, things that you might find in pro workflows and pro applications, that's where you see the up to 90 percent improvement over A10X. ..."
Apple’s Anand Shimpi, Phil Schiller talk silicon—”This is really an Xbox One S class GPU.”…
arstechnica.com
Those tuned threading loads are iOS and several selected iOS apps or random Linux and Android apps ? For example,
"... On iOS, 429.mcf was a problem case as the kernel memory allocator generally refuses to allocate the single large 1.8GB chunk that the program requires (even on the new 4GB iPhones). I’ve modified the benchmark to use only half the amount of arcs, thus roughly reducing the memory footprint to ~1GB ..."
www.anandtech.com
So how much time did the chip designers spend on MMU performance for 2-3GB user level memory workload and memory pressure which the OS blocks. ?
Sure, the main use case of Apple Ax is the iPhone. But there are few features in it that are all that iPhone-specific.
it is just as much an issue of missing features as it is ones that are present. Even those present are tuned to which workloads in the design phase.
This bet, which contrasts with Qualcomm going to more cores earlier than Apple did, works for multiple reasons: for one, Apple's applications typically don't have a garbage collector thread running. So that's a big chunk of background thread work (not to mention RAM use) gone right there. And two, a ton of work these days is still mostly single-threaded; JavaScript, for example.
this is more so about Qualcomm spending time and resources on a "server" processor which they eventually walked away from.
Broadcom may not have wanted to be in the Arm server chip business any more, but its machinations since it was acquired by Avago Technology two years ago
www.nextplatform.com
That was part of the whole issue of how Apple got to 64-bit ARM before everyone else did. Almost all of the other ARM implementors viewed 64 bit ARM as how to break into the higher margin server processor market. So had different timelines assigned to that implementation path. Apple didn't really care anything about the memory address expansion ( iOS proactively kneecaps apps in memory allocation as soon above). 64 was a path to dump some legacy ARM instruction baggage.. so Apple took that early. That was in part driven by the fact that iOS and their app software didn't want to use that other legacy stuff either and it lowers the workload on compiler/tools for Apple.... so they jumped on that path quicker.
Baseline ARM is trying to do multiple things. Apple ignores significant parts of those. The other implementors are often in business of building implementations for other folks to use to build things with. Qualcomm rolls out more Snapdragon processor variants in a year than Apple drops iPad+iPhone models in the same year.