In my experience a lot of technical decisions are about solving an immediate urgent problem, not really about a true discussion of tradeoffs. I’ve seen monoliths broken up into micro services because teams feel they can’t iterate on their problem fast enough. I’ve seen micro services turn back to monoliths because of difficult scaling/deployment/cost properties of so many little services. And then people argue from a standpoint of we had X problem we solved with microservices. People rarely feel the Y problem they’re not currently having.

Add to that the bias for the new dev/leader to push some change to show impact - you get a regular pendulum swing between extremes.

One problem underlying it all is stable engineering leadership. This itself is a challenging balance between stability avoiding dumb architectural churn like I describe vs ensuring you have some new blood to inspire fresh ideas. Another problem is just misatribution: we see X problem in the product, some eng pushes Y big solution to X even though there’s probably a simpler path to solving X in the current stack. Often you don’t really need to do that big revamp but to show impact? devs preference? we do X anyway.