I think this is what software engineering has almost always looked like. Computer science is definitely more pure and at the cutting edge of knowledge and implementations, but software engineering on the other hand is about understanding the tools available to you for your budget, and picking ones that will leave you with enough tolerances for your workload plus or minus expected variances, while expending the least of your budget. The longer you've been in your career, the more you have experienced the existing tools that are out there and can discuss those topics and weed out irrelevant details that some marketing department might tout because it's their tool's most favorable angle.

In short, computer science is algorithms, data structures, etc. Engineering is those things applied for a given set of constraints including time and budgetary constraints. Or at least that's how I've come to define the differences.

I generally tell my family my job is more like lego than anything else. It's about knowing the pieces available and how to put them together into something cool. And occasionally, you do get to build a new piece that brings the whole set together nicely if the brick you need doesn't exist yet.

Computer science has never been software engineering, though there's been a lot of cross-pollination.

But there's still a world of difference in my opinion between "how can I put all these tools together to deliver a solution to the problem" versus "oh crap, the service is running out of CPU again, argh, my service provider changed how we specify CPUs because the old way wasn't good for someone who isn't me, and okay, I'm upgrading, and oh shit the upgrade also changes how we get to the encryption keys and now it's busted, let's revert, what do you mean it irrevocably upgraded our key store to the new version and now the old version doesn't work, fix that then, oh, we can't because that's all in the cloud and we missed the upgrade emails in our other big pile of emails argh argh argh fine, call an incident and bring in half the teams in the company".

The latter was not created in the past 5 years, but it has gotten noticeably worse. When things work, they work better than they did before, but when things fail, they fail harder, in the sense that they can create much more complicated snarls than they used to. I much prefer even dull requirements elicitation meetings to too much of the latter.