I'll wait.
I would recommend you find a floor plan for Apple's M series chips and take a look at how big Apple's media engine is.
Anyway, here, I'm feeling nice. Some guy comparing the M1 Pro's HEVC encoder vs x265 (amongst others): https://colinmckellar.com/2024/01/11/video-encoder-compariso...
Here's the only graph you need to look at if you don't want to bother (encoding time vs file size at fixed perceptual quality, log scale axes): https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90...
We've got five generations of Apple's Media Engine shipping in M series chips.
If things are as dire as you claim, one of the many hardware reviews in reputable publications over the years would have mentioned this unacceptable quality at some point.
It seems like you are interpreting this as a slight against the quality of Apple's hardware encoders, which may legitimately be very good. As are Nvidia's, Intel's and AMD's. But all of them will produce larger file sizes and lower quality than equivalently optimized non-realtime software encoders, which simply have more information and more time, memory, and flexibility to compute over it.
We're talking about fundamental properties of compression and computational time/space trade-offs. Even Apple can't design around them.
That doesn't mean Apple's hardware encoder is in any way bad or unusable. All lossy compression will be imperfect, yet much of it is useful. And most modern codecs and encoders seem to be capable of high quality results. The implications of the differences under discussion are percentages of a bitrate or tiny nearly imperceptible artifacts or breadth of available resolutions, refresh rates, and color modes or codec choice. Software encoders are always at the bleeding edge of what's possible. Hardware encoders are necessarily a snapshot frozen in silicon with limitations imposed by the implementation. The middle ground is largely already occupied by SIMD and other transform-specific ISA extensions already present in most CPUs.