Sure, there's middle grounds, such as cortex-M4 MCUs with memory controllers for SDRAM.
They make sense in only select applications: once you have loads of memory, you either yearn for something that's very number-crunching, like an actual DSP as CPU, or even things that aren't microprocessors, especially FPGAs. Or, you need that much RAM to run multiple processes with isolated jobs, in which case, yes, maybe you're crossing over into lands where a memory-managing/segmenting OS on an application processor is what you actually need.
is still simple to program (maybe a simple RTOS but no MMU and processes and drivers )
I think you're forgetting that MMUs make writing software easy, not harder! If you think programming your MMU is hard, then you're probably not actually doing things with a lot of RAM in different processes, or your appreciation of "complexity" is skewed from what the rest of us consider hard to do right :)
Any embedded developer I've ever talked to will tell you that writing a service to run under Linux or Vxworks is way easier than writing a safe, reliable, self-recovering task on a microcontroller that handles a lot of data. An OS job is to make the developer's life easier. That developer being you.
... it also doesn't need high performance (probably not clocked a lot more than 100 MHz
I wonder why you need much RAM if you can't go through it performantly? Maybe a "small" microcontroller with a SPI RAM is sufficient for what you need. Or flash? who knows your actual use case...
at least a couple megabytes per second
That does sound like you want a CPU in the 100 MHz range or more, or you'll have little use for that much data. More than half a century of system design has yielded that for basically all microprocessor applications, you only need RAM that's significantly slower than the CPU is at processing data. (This looks different for dataplane applications, where a CPU the job of only controlling data flow, not ever touching the data itself, but I guess you're not building a network switch"