You are correct.

If the application fits well in an 8051, then it will probably work perfectly to store configuration, logg data or whatever in that big flash of yours. I guess you access it like a "database", either scanning through the data or requesting "records" based on some sort of index.

This kind of usage - normally done with large serial memories - can work very well with any processor architecture. But it works well because you have a situation where you have an application that can live with this constraint. Few applications can live with such a constraint for RAM memory. The most notable exception is very high-speed data logger memories (such as in a digital scope or a high-resolution multi-channel audio recorder) but then you normally use two-port memories or two access banks or similar so the data capture can be performed without involving the processor. To the processor, it may be just the read side of a single-address FIFO.

When someone needs a 8051 with very much RAM, then it is time to take two steps back and do a more complete analysis of the problem. The probability is high that the project is on the way into a solution that will lead to a lot of future complications and costs. The total system cost is almost always lower with built-in memory, and the availability of 8051 processors with much RAM isn't directly high. And that still leaves the problem with compiler support for working with large address spaces. The loss of direct addressing can have a significant effect on development and maintainance costs.