You join a new team put together to deliver an exciting new feature. Your team build a new thing, you choose frameworks, languages and process to support that. Direction changes, your organisation wants something new. All your precious work to “standardise” now makes it hard to react to change.
A new team is formed to respond to the new direction, they don’t want to use the existing frameworks, languages and process as they aren’t familiar with them, the last team write bad code, or used a confusing framework. They build a new thing, they choose frameworks, languages and process to support that.
Repeat.
This process is wasteful, frustrating and dangerous as the stability of existing services is compromised.
Your work will always get thrown away, build as if that is going to happen.
The reasons for your services to exist might persist but the circumstances that allow your team to develop on them might not.
Software libraries will always eventually be unmaintained and become a drag on future development (especially libraries your team has written).
Some future developer will get frustrated and throw your work away because it’s always easier to understand your own work than someone else's.
Your programming language/framework will become unpopular and outdated.
Great engineers in your team will leave.
Your team will be replaced.
Build so that your services can be replaced or removed easily.
Use easy to understand and adopt interfaces in development, build and deployment.
Don’t force another developer into patterns that are easy for you because they are familiar to you.