Question is how easily that limit can be changed. Maybe there is a single constant defined in the operating system which decides the maximum number of cores, and that number can be changed from 64 to 128 or 256 or something bigger. Maybe someone decided "we will never have more than 64 cores, so we don't need to change this" and that limit is built into many places. We don't know. But with 56 virtual cores available in actual machines today, I would have given someone the task to make this changeable a while ago.
The question really is how much does Apple want to push such a change into the kernel of the iOS , tvOS , and iPad OS. Not much.
It is a data structure problem not a 'constant'. Need to keep a bitmap of the processors in part so can do assignments of work allocations , affinities , etc. The core work the central process/thread scheduler does. If using a 64 bit 'word' to track the processors then more than 64 is a hard cap set by the data structure.
Can wave hands and say just flip that to two 64-bit words but that change will ripple all through the scheduler. The scheduler also has real time constraints that also have to still meet. Also start to get more NUMA effects that long and broader the core interactions are which also figure into scheduler allocation heuristics.
This is all "doable". But typically there is a mild 'fork' between the server scheduler and the mainstream scheduler in the OS. Apple doesn't have a separate server OS track. They didn't even have a seperate track back when they had a "Mac OS Server" product. It always was basically set of applications bundled, not a fundamental retuning and/or customized kernel core for servers.
HFS+ began to fork between iOS and macOS. Apple went to AFPS to merge those back into a more manageable unified set of code. Most of APFS is geared toward a single , internal , Apple built , SSD drive. Larger high end multiple petabyte data integrity features would see in a server oriented OS ???? .... nope. No where to be found.
Multiple storage disk management. Outside of a mild kludge for Fusion drives .... nope.
macOS 11 on ARM cover multiple GPU implementations? nope. ( at least on now and wouldn't be surprising stays in place until macOS 11.1 ).
It is pretty clear which product is running primary lead on common kernel development. It isn't the very high end Mac Pro user base. The norm of the kernel feature set is aimed at iPhones , iPad Pro, and highest volume Mac laptops. That's probably where Apple is going to continue to put the bulk of their kernel development resources. Apple is putting far more effort into kicking 3rd party extensions out of the kernel then chasing a mega monster next iteration of the Mac Pro.
On the other hand, there may be bottlenecks that are Ok(ish) with 64 cores and hit hard when you have 100.
AMD's Threadripper products have suffered numerous performance blocks with Windows kernel scheduler and allocator mismatches between the system design and the OS. And Microsoft is trying to cover a far more diverse set of CPU designs. Apple isn't. It anything Apple will likely be doing a smaller set of design variations once they move to Apple Silicon , not a larger set.
It is just far lower effort for Apple to just throw transistor budget at Apple specific fixed function ( image/video processing , apple specific ML cores , integrated GPU 'cores' ) than chase the "insatiable x86 core count application workloads." . Mac aren't going to do 'scale out' or 'scale up' data center deployments for the most part either. ( some in the relatively narrow niche Apple plays in now where just trying to stay on legal side of virtualization and run macOS images, but broad generic workloads ... no). For fixed function logic all the OS/apps have to is dispatch work to them and it comes back 'done'. Not much additional scheduling work to do there other than perhaps 'wake' up when done.
