That's a direct outcome of the contemporary fashion that code changes should be as narrow as possible and only touch existing code where its strictly necessary to their implementation.

It's not the only way of working, but it tends to suit the challenges faced by very large teams with high turnover, diffuse/negligent code ownership, many juniors/early-career contributors, and low trust.

It also produces software that resembles papier maché -- increasingly thick, disordered, and glutinous, with poor visibility and low durability.

If your team isn't subject to the challenges that make papier maché coding necessary, encourage people to escape its cargo cult. Small teams of people who trust each other, where code has long-term owners who can speak to its purpose and direction, can dynamically sculpt and rework code more like clay. And you get better software when that can be done.