Because it's not wear. Wear can be measured. Wear is predictable. This again comes back to the mental model.
>most modern OSes now experience major changes once every 6 months, often with alternating (1 year) "LTS" releases
For the OS, this is a fair point. Maybe it should be mandatory to plan for OS updates, which often cause a host of issues.
>some ways the software industry still maybe needs more of a better defined engineer/mechanic split than it has today
I think the reason we don't have a proper split here, is because a split here isn't really possible. Maintenance work _is_ engineering work, you need good judgment to decide whether a dependency update is ok.
A proper test suite can help make the maintenance easier. But there's no mechanic equivalent, since there's not necessarily modular parts to be replaced when interfaces change.
I think all in all we need to move away from engineering analogies. SW engineering is different enough that these analogies do more harm than good. And in the end we should have the self-confidence to ask our managers to understand software as its own discipline.
If a manager doesn't understand what they're managing without heavy-handed analogies, they are in the wrong position.
(The other thing that this framing calls to mind is that a company doesn't usually send a civil or mechanical engineer to do the general maintenance checks, they first send a cheaper mechanic or other equivalent laborer. This is both where the analogy partly falls apart because not all software maintenance tasks in these 6 month timeframes are "easy"/"trivial" and sometimes need massive software engineering work, and also where we again maybe see hints that in some ways the software industry still maybe needs more of a better defined engineer/mechanic split than it has today.)