Just speaking very generally and simplistically, and without considering the details of virtual memory implementations, the developer always has knowledge in foresight that the VM implementation lacks.
The developer can always say, "I don't need to load this audio file right now. The music inside is only used for the game over screen." And immediately after the game over screen, the developer can say, "I don't need this audio clip anymore in physical memory. It's only used for this game over screen."
The OS has no such foresight. It might be able to figure out, many page faults later, that some audio clip is no longer needed in physical memory since it hasn't been accessed in a good while. But turning foresight into hindsight translates into lots of page faults, and lots of page faults translates to hiccups in frame rates in a software as time-critical as a video game. There the foresight of the developer really helps if you want to avoid such hiccups.
And that applies conceptually regardless of the hardware and software. Assuming paging in memory is expensive, then the developer's foresight will always help in reducing that expense.
Speaking even more broadly, there's a never-ending cycle between hardware designer, compiler designer, OS/driver designer, and application developer. The hardware/compiler/OS/driver developers often try to implement optimizations to speed up your average application based on its usual memory access patterns, and perhaps sometimes with the hope like, "People should just be able to write code however they want and it should be fast." But if there was any thought of that type going on, it usually fails for performance-critical fields, because then the performance-critical developers start learning the intricate details of their compiler, hardware, OS, drivers, etc. and start writing code specifically designed to exploit that as much as possible to write the fastest code possible (like prefetches, hot/cold field splitting, SoAs, etc. for cache-friendly code). And that's like a game that never ends. These things are never treated as black boxes in performance-critical fields, since the developers are competing for performance.
Personally I kinda wish virtual memory didn't exist since it adds an additional layer of performance unpredictability in ways that tend to be too extreme and incur way, way too much of a performance penalty when things go really south to the point of unusability. I have sometimes run into cases where I used some application where I typed an extra digit or two by accident when drunk into some input field which then caused it to exhaust physical memory so quickly in ways that brought the OS to a crawl where I couldn't even click the cancel button on the progress bar anymore and had to wait 10 minutes while jamming Ctrl+Alt+Del to kill a process and cursing to myself while spilling my drink to get back to a point where things are usable again, and that was in spite of the page file being stored on an SSD. In those cases I would have rather preferred an "out of memory" error or something, at which point I might close some of my 17 tabs of porno (it's okay, I bookmark my favorites anyway) to free some memory and then immediately go about resuming my business.