I'm sure many of my fellow @SalesforceDevs would agree, Triggers are an antipattern and is the main reason "code" gets such a bad rap in the #Salesforce ecosystem. Here’s why:

Triggers and/or the entity event listener pattern has been around for decades and Salesforce being a heavily Oracle based house, probably liberally borrowed from relational database triggers:
https://docs.oracle.com/cd/B19306_01/server.102/b14220/triggers.htm

In fact, the problem is not just Triggers, Salesforce provides so many automation tools hooking into the “Save" lifecycle of an Object; All of them contribute to the problem.

I think these “Save" event based automation tooling fundamentally break the Open-Closed principle of good software design because they are not easily extended without affecting other parts of the system.

Developers should explore other options like Screen Flows and/or lightning components as the Sources of events (such as a button click) and avoid hooking into the save lifecycle. Decoupling business logic from the Save lifecycle event requires some clever UI/UX rethinking.

The save lifecycle should probably be used only in cases where we need some logic to preserve the invariants of an object.

Another valid to hook into the save lifecycle is to issue confirmatory “Notifications” or to spawn any further processing asynchronously. The key point is that this additional code is NOT part of the original Save transaction.