There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.
The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.
(Note that 'purpose' might be 'allow us to process this one batch of files' or it might be 'provide a stable, maintainable infrastructure for our product for the next 20 years'. It's just important not to lose sight of that purpose either way!)