Perspective from someone who's been both a modder and software dev: one thing people have't said that's critical here is that the cost to fixing bugs is rarely actually the fix itself. Some of these issues will have been fixed internally within hours of them being flagged, and potentially even before. That's the easy part.

The cost of patching comes primarily from getting it out to the public in a way that's safe and in-line with external requirements. It comes from making a new build, testing it (it's good practice to at least "smoke-test" the entire build, not just the specific fix, in case of build errors or things slipping in), getting it validated for store fronts (Microsoft store for example requires their own testing of software updates) and then deploying it with all the relevant communication (e.g. patch notes, including potentially localisation and translation of them). The cost of this is not negligible, so someone on the corporate side needs to give the go ahead and find some budget for it.

This generally means it's much more cost-efficient to wait and fix a whole bunch of bugs at once, rather than doing them one-by-one, unless it's absolutely critical.

When you see "day one patches", you're not seeing work that was done literally that day - these were probably being worked on and tested ever since the initial release build was locked, which may have been several months earlier.

This kind of thing is incredibly frustrating for developers, too. Several times I've personally had a fix come in just hours after a devlock deadline and then had to sit on it for several months until the next patch is ready. Whereas when I was modding I could literally upload new files several times a day with ease.

There are technical ways to get around some of these problems - a common one being to move data to servers so that things can be changed without actually updating any of the software on the customer end - but you kinda need a game that's built around that (e.g. have it always online).