If the 68k family had continued to evolve past the 1994s 68060, I'm sure they could have just dropped backwards compatibility to some of the more complex addressing modes, or just devoted less silicon to them, and making what remains faster. Kinda like happened with the ColdFire version of the 68k family.
What really killed the 68000 was the move to RISC, in particular Apple's move to PowerPC. That took away any hope of future evolution (they even managed to release the 68060 after that, but that was it) and collapsed the high-end 68K business.
The Motorola Series 900 machines were interesting - I had one under my desk at work for quite a while. They had stackable units, including one that contained a SCSI 3.5" floppy drive that was way faster than regular ones. We also had a DG unit with the m88k.
> That was possible only because at the time, memory was faster than the core and could keep up. Modern CPUs run the core at several times memory speeds, and there is latency involved due to physical constraints.
That begs the question: Would we be better off if CPU clock speeds were set such that the memory could keep up again, and we software developers learned to work within real constraints again, rather than expecting the CPU makers to keep working miracles to deliver ever more performance? I have no wish to go back to programming in Applesoft BASIC or 6502 assembler as I did in my childhood and early teenage years. But programming a 32-bit processor clocked to match the speed of memory, in C++ or Rust, wouldn't be so bad.
Absolutely not, because of the locality principle. As Terje Mathisen used to say, "All programming is an exercise in caching."
Locality isn't a property of a specific coding style or methodology, it's just the way programs work. No matter what kind of architecture we end up using 50 years from now, it will have a fast cache of some kind, backed up by slower memory of some kind. We'll have a different set of problems to confront in day-to-day development work, but hobbling the CPU won't be the answer to any of them.
Power efficiency is more complex, often it's better to briefly burst then get back to sleep faster, rather than drag things out at 100 MHz, but a specific answer would depend on many factors.
Memory latency is at best about 10 ns. I don't think a 100 MHz CPU would better in any way than what we have now. Well, except power requirements would sure be very low.
I think one of the factors could be that 68k is a bit harder to decode than x86 - while the instruction set is more orthogonal, the encoding has less structure; compare http://goldencrystal.free.fr/M68kOpcodes.pdf (68k) with http://i.stack.imgur.com/07zKL.png (x86).
very fast (single CPU cycle) memory access
That was possible only because at the time, memory was faster than the core and could keep up. Modern CPUs run the core at several times memory speeds, and there is latency involved due to physical constraints.