I think it may be possible you live in some kind of js bubble - I have never heard of those things and it wouldn't be something I'd advise anyone to do.
yeah I really don't understand this "catch them out" mentality.
My approach is to try and make the candidate feel relaxed, as I want them to show their best self in an already stressful situation. Following this it's about giving them the opportunity to demonstrate their skills.
If you go into an interview with a combative mindset of "filtering out the lemons" and then complain how hard it is to hire good people, you really ought to take a long hard look in the mirror.
The ops engineer was probably trying to do you a favour / make it so you don't look ignorant and grumpy. Try to assume the best in people and their actions and your life will likely be better for it.
The job is over, with very little to be gained dwelling on trivialities.
I've worked with these super-smart idiot savant type engineers before and often butted heads over stuff, and later in my career lead teams that have those archetypes.
A few things I think - one is stress that they might be clever enough to understand and manage that kind of complexity, but you personally aren't, and would prefer styles, solutions and techniques that are comprehend able by mere mortals such as yourself. This is hard if not impossible to argue with. After all, you need to be able to understand it, because if they leave or are unavailable the maintenance burden will be on you / the rest of the team.
But the flip side is these people are usually very good problem solvers and prolific, so the more you can harness that, the happier everyone will be.
Some of my regrets include stalling a PR for being overly complex, resulting in it not getting merged and deployed for months, when the code would have saved 10k/month in server costs. When I tried to re-write it myself to be simpler I failed, so it was arguably necessary complexity. With that said the team that took the code after us, removed the feature entirely as it was a complicated mess - that was probably the sensible but outside the box solution.
Another one was early in my career working with a senior who liked short/scope relative names. I thought it was bad naming at the time, but now I realise that if you do it properly, the shortness itself can be semantic.
The biggie for me is tests, many people dislike writing them, and occasionally the smarter guys can get away without them, more so than the average. But long term, this creates a nightmare because the team will lose confidence when making changes. Convincing people to write more tests is difficult and I haven't worked out a great way to emphasise why it's necessary.
If you do all the hiring yourself, what is to stop you hiring someone to do all the stuff you don't want to do ?
I am sure you could bring in an engineering manager, project manager, technical product manager or whatever you feel is the most appropriate job title to palm off the aspects of the job you are less keen on.