Another way to look at it is that a game is essentially a collection of files on a hard drive. There are files that contain or describe audio information, or 3d models, or image textures that get applied to 3d models, or animations, or logic code that performs functions etc. There can be tens of thousands of files.

As you can imagine, keeping track of all those isn't easy. So quite often what happens is a whole file directory and management structure is included in the game. Sometimes you can see the layout of that in the games installation folder but it's more common for the game to package it all into one or more large "container" files. Think of it like how a Zip file works, as lots of files within one big file.

And normally that file management system has a way to distinguish a newer version of a file from an older version. So it doesn't have to delete the old file, it just points the game to the newer version. And if that older file is "inside" of a container file it can't easily be deleted anyway. So normally games don't bother to delete old files.

What's normally actually happening when you patch a game is you're rebuilding that internal directory structure from the container files. The patch contains newer versions of existing files and it copies all of those into the games installation folder (either individually or all at once in another big container file) then it instructs the game to rebuild that directory tree and update it's list of newest files to use.

And that works because when you're playing the game and you e.g load a new level, the game isn't really asking Windows to open a file at C:\Games\MyCoolGame\Levels\2.lvl, the game is asking itself to load the file from it's own internally maintained directory at \Levels\2.lvl. That triggers the "find the newest version" step and that's how the game loads the patched versions of files.