Ya I miss the 68000. It was the first assembly language that I learned. It was much closer to RISC than x86 is, so there were plenty of registers and the instructions were fairly generic so it was straightforward to map C code almost directly to assembly. The "32 bit clean" stuff caused a lot of bugs for years after 32 bit memory arrived though.
What really killed it though was perceived slowness. Apple insisted on shipping generations of Macs with crippled busses running at half the bit width of the CPU and/or at reduced frequencies.
I remember the very fastest Macs in the early 90s not being able to even run a scrolling 2D game at 640x480 in 8 bit color because it just wasn't a priority. Meanwhile a 486 could run DOOM in 320x240. We had to wait until the 60 MHz PPC 601 arrived, and even it struggled with 640x480 graphics (the lowest resolution available). On top of that, most software was still emulated 68000, so the perceived slowness of Macs continued until Steve Jobs returned and introduced the colored iMacs.
I eventually came to love x86 assembly for the brief time I used it though. It has so many easter egg instructions for moving bytes around wider registers and getting free side effects with memory access that it felt like there was always another way to gain a bit more performance out of hand-rolled loops.
Of course that's all gone today, because instruction sets are so.. byzantine that a good compiler will usually beat hand-rolled assembly. That's because the real processing happens as RISC beneath microcode so a human can't really know the optimal way to string instructions together to keep the pipeline full or avoid cache misses. Also the SIMD stuff expanded the solution space to such a degree that it's almost pointless to do anything directly. Better to use a vector language like MATLAB and compile to SIMD accelerated C or go to GPU processing instead IMHO. Otherwise you're perpetually struggling with premature optimization and can't work at a productive level of abstraction.