Analogue output is actually easier that's why it's done. Here, you just have to push out some signals at the right (slow) timing and you get a picture. DVI/HDMI requires pretty decent technology to do effectively.
Let the "framebuffer chip" handle the timing sensitive HDMI/DVI dance, and then you can use the general-purpose controller for things like "map a more well-supported graphics protocol to this language". If the controller fails to meet a timing requirement, the framebuffer chip doesn't cause the monitor to lose synch, you'd just get a torn image because it wasn't fully populated in time for the frame to render.
What I've been waiting for is some sort of "modern MCU as replacement for expensive, clunky, slow old video cards." It seems like if you want to use something like a Pi Pico, it would use almost all of the resources just to maintain synch and timing, so it might not be amenable for the other half of the job-- monitoring the external bus and waiting for inquiries on the framebuffer/firmware/support register address ranges.
The Pi Pico has 2 cores so while one core is used entirely to maintain the display the other core can do other things.
One constraint is VGA is at minimum around 25mhz and HDMI is at minimum 165mhz and a pico is around 133mhz.
It also takes clock cycles to update the data and run algorithms. Some of the algorithms can often be mitigated to the silicon that controls some of the pins as they can have small bit of programmable logic for this purpose or can be re-purposed, but usually not all the pins or all of the algorithms.
There are tricks and such that might be able to get it working in certain lower resolutions and color modes, perhaps like overclocking or taking advantage of some harmonic, or clever use of some existing feature, but the more tricks you do to get things faster,often introduce issues with stability that you have to mitigate or solve. This barely touches physical constraints like cord length, signal integrity, voltages and current, overheating, etc that may or may not be applicable.
X x Y x colour_bytes x frames x 8bits
Eg, 1280x1080x3x60x8=1.99Gbps
So at 133Mhz, each cycle the RP2040 would have to push 15 bits out. It's got 2x cores, can be overclocked at double reliably, and has a bunch of programmable IO machines, so maybe doable, but likely not 4K. (More around 10-20Gbps.)