Risk mitigation and investment; my employer's software does critical mobile network infrastructure, if they have an outage it affects millions of people. So, if our customers upgrade the software, they want to do their due diligence in their particular use case (it's a flexible system).

That said though, software should be built to allow for fast and painless upgrades. Backwards compatibility and many use cases should be tested automatically and constantly. But, it's a big investment to have software like that, and you need to resist a lot of younger, eager developers that want to e.g. introduce a new language or make sweeping changes.

Our customers don't want to spend vast amounts of time qualifying an entire new release when they can accept an isolated fix instead and do more focused testing. They might need the fix for some critical part of their product. If I was them I'd do the same - if the rest ain't broke, why risk fixing it?

We have a complex product with many aspects that our customers use, and almost all with some customized integrations.

A bugfix to the integration is typically low risk and high impact, and so the client will want to install that ASAP. For example it could be they suddenly changed the values in a single field in an XML file we read, due to upgrades elsewhere in the organization yay, halting the integration.

So we push a fix where we handle the new values, and they want that installed ASAP.

What they do not want pushed out into prod without lots of testing is all the new things we've added elsewhere in our product, or larger changes to existing features.