I can take a shot at it, sure. It's nothing magic, but it is something that's hard to replicate across the rest of the computing world.

Apple has vertical control of the entire ecosystem. This means that you will be compiling your code with an Apple compiler, to run on an Apple OS, that has an Apple CPU powering everything. There is very limited backwards compatibility, and no need for legacy support. The compiler can thus be far more aggressive in terms of optimizations, because Apple knows what, exactly, makes the CPU performant and what kind of optimizations to use. They can also control scheduler hinting and process prioritization.

Their CPUs minimize bottlenecks and wasted speed. Rather than being a self-demonstrating non-explanation, I mean that they do a very good job of not wasting silicon or speed where it wouldn't make sense. There's no point in spinning your core clock at meltdown levels of performance if you're stuck waiting on a run out to main memory, and there's no sense in throwing tons of integer compute in when your frontend can't keep the chip fed. Apple's architecture does an excellent job ensuring that no part of the chip is running far ahead or behind of the rest.

They have an astoundingly wide architecture with a compiler that can keep it fed. There are, broadly speaking, two ways to make CPUs go fast: You can try to be very fast in serial, which is to say, going through step A -> B -> C as quickly as possible, or you can split your work up into chunks and handle them independently. The former is preferred by software folks because it's free - you don't need to do anything to have your code run faster, it just does. The latter is where all the realizable performance gains are, because power consumption goes up with the cube of your clock speed and we're hitting walls, but we can still get wider.

This form of working in parallel isn't exclusively a reference to SMT, either, it's also instruction-level parallelism where your CPU and compiler recognize when an instruction will stall on memory or take a while to get through the FPU and moves the work order around to make sure nothing is stuck waiting. The M series has incredibly deep re-order buffers, which help make this possible.

Apple has a CPU that is capable of juggling a lot of instructions and tasks in flight, and compilers that can allow serial work to be broken up into forms that the CPU can do. This is how Apple gets such obscene performance out of a relatively lowly clocked part, and the low clocks are how they keep power use down.

ARM architecture has less legacy cruft tied to it. x86 was developed in an era when memory was by far the most expensive part of a computer, and that included things like caches and buffers on CPUs. It was designed with support for variable width instructions, and while those are mostly "legacy" now (instructions are broken down into micro operations that are functionally the same as most ARM parts internally), but they still have to decode and support the ability to have variable width instructions, which means that the frontend of the CPU is astoundingly complex and has width limits imposed by said frontend complexity.

They have a lot of memory bandwidth. This one is simple. Because they rely on a single unified chunk of memory for everything (CPU and GPU), the M series parts have quite a bit of memory bandwidth. Even the lower end parts have more bandwidth than most x86 parts do outside the server space.

There's more, but that's what I can think of off the top of my head.