If that is their current culture, there will be a lot of pushback if you want to initiate changes. Especially among the senior (responsible for the mess) ones who get defensive real fast.
Maybe ask more about how their engineering culture is next time around during interviews.
The devs in teams I've worked with (including me) are most of time all quiete aware of the places where their code en setup is lacking and as long as they don't feel personally attacked are very happy with people who come with implementable solutions.
The not feeling attacked and implementable parts are key.
And I've always liked it personally when somebody does that to me. When somebody with a lot more experience and/or skill helps you, it's like some super high level player carrying you through boss fights: you level up much quicker than if you did it on your own.
But I've seen people giving negative responses to the best feedback. Hell, I've had people complaining for hours because someone else replaced their manual process that took an hour to do with a script (and copy&paste of the result) that took literally seconds to run.
I've never personally seen somebody getting fired because a script can do their job. I've seen them being freed from doing the same repetitive bullshit day after day though, and finally being able to actually tackle new challenges.
But unfortunately, that kind of mindset is not something you can change through rational arguments, at least in my experience.
But I agree with the last sentence. This is a huge mistake, and it seems that the author did not ask these proper questions during his interviews. Perhaps, this is the most valuable lesson to him from the story. You have to know which company you are going to join and the state of engineering.
I've been trying to improve our standards for years, it never gets traction.