That being said, in my line of work (academic research, not production code), I've learned that for much of the abstraction, the juice is often not worth the squeeze.

In production code this can be the case too, it depends on what you're building for. You have to be smart about what you spend the effort on. If you abstract everything away, you're overengineering. If you just C&P everything, you're underengineering. There's a sweet spot depending on what you're after. When there's no threat because it's expensive to replace your product, it's easy to slack off. The proprietary software space is filled with this. I know because I've worked in it for decades, always battling both the workfloor and the customer to get to maintainable software. No longer moving in that space - in favor of doing volunteer open source work - was the best choice I ever made (except for slowly becoming a pleb, lol.) Because when you develop in public under a permissive license, you have to make good choices. There's no obscurity because anyone can just fork you away with a click of a button. Much less trickery.

The barriers for a small business to write their own bespoke software has gone down a lot

I've had real fun in the past helping mid-size or even larger orgs deal with lock-in as gig work. Just relentlessly produce software that utilizes every API it can, or even scrapes the shit out of web forms, to get stuff done right. I no longer get that type of gigs though - and if I did it would be a couple days of work instead of a couple of weeks. Much has changed.