In a vacuum, yes. But depending on your project setup (both technically and human-resources wise) that can be difficult or prohibitively inefficient to do. It’s also often the case that features that seemingly should have little or nothing to do with each other ends up doing so, so a bugfix in feature A ends up breaking a corner case on feature B. If it wasn’t documented that feature A and feature B shared any kind of relationship, then it’s easy for that kind of thing to slide “under the radar”.
That’s not to defend such things as building pieces exploding upon update (most recent example: corner stairs) - that really should have been found out before it went live (in an automated test, preferably).
Even though I understand and acknowledge that it’s not always easy, I’d still prefer somewhat smaller patches and content updates though, no question. Maybe not single-bugfix-patches, but there has to be a happy medium somewhere between mega patches that changes two core systems and adds one or more entirely new ones.
All of the above is based on practical (ie, far from ideal) experience, game/software development “theorists” will often have a multitude of techniques and processes that they claim prevents this - some are genuinely useful, others are more of a hindrance, none of them (in my experience) completely eliminates these kinds of issues.