There are no simple figures what is "enough" memory in a processor, even if the developer is skilled. It's just a question of what type of problems that are solved.

Ask Erik for example - when playing with displays, he wants frame-buffer memory for his pixel-mapped displays. The amount of RAM, and the bandwidth allowed for sending out the data, defines how large display that can be serviced with one processor, before it gets time to add in more processors.

On the other hand, the advent of FRAM memory has greatly changed the ability to use large nonvolatile memory to store large amounts of data even if that data needs to be regularly modified. With older technologies like EEPROM or flash, it isn't possible to use serial or parallell-connected nonvolatile memory as scratch memory since it is quite easy to run through 10k, 100k or 1 million write cycles. And advanced wear-leveling algorithms can help in some part, but does require an extra layer of complexity that both slows down an application and potentially adds hard-to-catch bugs.

But in the end, it will be simple to find suitable embedded projects where a processor with quite low computation capabilities may be used, but where the amount of storage space for quickly changing state information may be quite high.

When extending an existing project, it is normally easiest to keep going with the same processor architecture, and find something with more internal RAM, or find cheap external memory chips to add. When starting from scratch, it is normally better to not be locked into the existing knowledge of processor architectures but to instead shop around among the large number of architectures that exists, to find a cheap solution that seems to fit well to the problem and that may have better growth capabilities in case the product is a success and people starts to ask for upscaled deluxe editions of the product.