Good software engineering is all about managing what subset of the project should be an abstraction and what part of it needs to be a custom data structure/algo

Good software engineering is all about managing what subset of the project should be an abstraction and what part of it needs to be a custom data structure/algorithm/multi-threaded processing routine to meet the behavior and performance requirements. The question is how much of your time to you want to spend writing the abstraction to suit your needs or how much are you willing to bend the requirements to fit something off-the-shelf. If few of the operations your software needs to do are just business logic and database transactions, you expect to be called each time the thing needs changing, and the only people making the changes are going to be programmers, then it would be foolish to import some heavy-handed external framework: You should then abstract only to the extent that it makes the business logic easy to understand and makes the tedious part go faster. If, instead, you have a 'typical use case', with database inputs and database outputs, and an army of domain experts who aren't programmers using the tool, then it absolutely makes sense to use some heavy, featureful, off-the-shelf abstraction. If you've never had that situation, then that tool does probably look unfamiliar and undesirable. But be aware that both kinds of environments exist. Also be aware that it's the tendency of a growing or acquired business to move from the former to the latter.