Probably. But wouldn't that be dedicated hardware, like Quicksync? I bet it is slow as heck on the actual CPU of the SoC.
Why would you want to do it on the CPU?
THAT is the basic problem with your analysis; you're living in the past. Most of the examples you want to give of highly tuned x86 code that don't have ARM counterparts don't have those counterparts because no-one in ARM/Apple-land cares.
Video/audio/image encoding are done with dedicated hardware. Likewise for crypto. Likewise for some types of compression (it remains unclear just what compression Apple still does on the CPU, doubtless with tuned ARM assembly, vs what they have already moved to accelerators.)
So what's left?
There are things like highly tuned interpreters. If you care about running Lua or Python on ARMv8 it MIGHT be slower. Obviously JS is just fine. Anyone have any real data?
There is also highly tuned numerical code. When I compare Mathematica on iMac Pro to Wolfram Player on A12X iPad Pro, for the most part they are comparable in performance, but there are clear areas where Wolfram Player substantially lags.
Most of these differences appear to be policy choices by Wolfram as to how performant to make Wolfram Player so that it doesn't compete too much with Mathematica (eg the parallelization/vectorization support is abysmal).
But there's clearly a non-policy issue with the bignum support, which is just terrible --- that's probably the one (and only) real-world case I am aware of where highly-tuned x86 code has not (yet...) been rewritten to highly-tuned ARMv8 and is probably just using straight C.