You can see this well from the kennel's proactive swapping. If I run a bog standard desktop Linux distro and leave swappiness at the default 60, after a few hours of normal usage where I don't even get close to filling up my RAM with actual memory allocations from processes, the kernel will have swapped out almost a GB of data from several background services. Because a lot of programs allocate some memory for something and then never look at it in a long time. So it makes more sense to swap that to disk and instead use that ram as page cache.
Also, with current NVMe speeds, swapping has become a lot more bearable. Really the only place where I can see why you wouldn't use swap is servers with a well defined, dedicated workload. Here I indeed want a fast and noticable fail mode in case a new version of whatever I'm running might have a memory leak, or just vastly different behavior regarding memory usage.
When a workload runs out of RAM, it often really runs out of RAM, and would just be swapping continuously. It may even run out of swap space, if it was left to run for long enough. In my experience, even with NVMe drives, it just wasn't worth it because it usually wouldn't be able to finish in a reasonable amount of time. In part, I'm sure that's because the Linux kernel behaved much worse than is theoretically possible.
This may obviously depend on your workload, but I've heard similar sentiments from others (in fact, it was somebody else who suggested disabling swap to me based on their experience). The other point is that a sibling comment mentions some recent kernel changes that may have led to improvements, but I haven't given those a chance.