PnP will always work for a simple+direct+modern (GPU → DisplayPort or HDMI → display) display path; but there
are a lot of people who for whatever reason still need to use VGA.
Despite EDID being invented during the VGA era, it wasn't invented at the beginning of it — so older VGA displays don't support EDID, and therefore don't support reporting their valid modes. (And this is relevant not just for CRTs, but LCDs too — and especially projectors for some reason. Some projectors released as recently as 2010 were VGA-only + non-EDID-reporting!)
Remember Windows saying "you proposed a new monitor resolution; we're gonna try it; if you don't see anything, wait 15 seconds and we'll undo the change"? That's because of expensive mid-VGA-era EDID-less VGA monitors. These were advertised as supporting all sorts of non-base-VGA-spec modes that people wanted to use, but came with nary a driver to tell Windows what those modes were — so Windows was in that era just offering people essentially the same experience as editing xorg.conf to add ModeSet lines, just through a UI. And obviously, if even Windows had no proprietary back-channel to figure out what the valid modes were, then Linux didn't have a penguin's chance in hell of deducing them without your manual intervention.
---
But also, people are often trying to "upcycle" old computers into Linux systems (embedded systems like digital-signage appliances being especially popular for this) — and these systems often only come with VGA outputs, and video controllers that don't capture EDID info for the OS even when they do receive it.
Hook an early-2000s "little guy" (https://www.youtube.com/watch?v=AHukN0JsMpo) to any display you like over VGA, no matter how modern — and it still won't know what it's talking to, and will need those modeset lines to be able to send anything other than one of the baseline-VGA-spec modes (usually 800x600@60Hz.)
And this is, of course, still true if you try to use one of these devices with a modern HDMI display using an adapter.
(You might think to get away from this by using a "USB video adapter" and creating an entirely-new PnP-compatible video path through that... but these devices are usually old enough that they only support USB 1.1. But hey, maybe you'll luck out and they have a Firewire port, and you could in theory convince Linux to use a Firewire-to-DVI adapter as an output for a display rather than an input from a camcorder!)
---
Besides the persisting relevance of VGA, there's also:
• https://en.wikipedia.org/wiki/FPD-Link, which you might encounter if you're trying to get Linux running on a laptop from the 1990s, or maybe even a "palmtop" (i.e. the sort of thing that would originally have been running Windows CE);
• and the MIPI https://en.wikipedia.org/wiki/Display_Serial_Interface, which you might see if you're trying to do bring-up for a new Linux on a modern ARM SBC (or hacking on a system that embeds one — a certain popular portable game console, say.)
In both of these cases, no EDID-like info is sent over the wire, because these protocols are for devices where the system integrator ships the display as part of the system; and so said integrator is expected to know exactly what the specs of the display they're flex-cable-ing to the board is, and write that into a config file for the (proprietary firmware blob) driver themselves.
If you're rolling your own Linux for these systems, though,
then you don't get a proprietary-firmware-blob driver to play with; the driver is generic, and that info has to go somewhere else. xorg.conf to the rescue!