Hopefully they were justified in their choice.
Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations.
I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.
That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job.
You obviously haven't looked at the code for some of the Ansible modules!
There are many things I don't like about Ansible and I don't think it's particularly robust, but it is an improvement over manually written scripts, most of the time, because writing robust scripts is not easy.
What I think "senior developers" are usually disparaging is using tools like ORMs without appropriate understanding of how they work, and thus being unable to recognize when they don't suit the task at hand.
Of course, years later when I finally dug into SQL and interacting directly with databases, I had a much better understanding of their mindset and wish I would have learned earlier.
Now your mindset feels very similar to me - "I'll write my own shell scripts, thanks." So, to avoid making the same mistake twice, do you have any advice for what to read / learn to better understand your position?
Note: I've written plenty of shell, but the shell I've writen is way to hacky to use as a replacement for ansible.