You'd want to use db connection pooling for any nontrivial application, a goroutine per db request is a recipe for connection exhaustion. That being said, go's concurrency model is indeed a huge selling point of the language.
There are such situations (people and places) that command one to put their mindset in "agreement mode", not because of logical reasons¹, but absent or even contrary to those, because of a need to reduce friction². In this meta-knowledge space³ lies the solution space⁴ for all your problems in a human environment.
When you approach things like that, you tend to see where "tech" fits in a wider landscape, and it tells me when to speak and when to shut my big nerdy mouth (whenever it's counterproductive, e.g. premature abstraction⁵ is just as bad as premature optimization). It tells me which lines in the code are "political", "organizational", "structural" not to the tech but to the humans around; and by elimination, which lines are left for us nerds to think about deeply.
It's a dance, really, there's no right/wrong/perfect, but there's a certain way to rise above these human contingencies and actually facilitate the path to market while having a blast — just set your expectations right as to what you can and can't touch, at least for now, reassess on a need-to basis.
So when you see a dark "anti" pattern (OP's case), sure you naively ask 'why', but then if you see org/pol structure, if you see this rigid wall of "this is how we do it, this is who we are", you know it's not about tech anymore. It's personal. Don't hit there. People (especially when insecure, so all of us at times) tend to protect their knowledge like it's a judgment on themselves, like it's proof of their worth, and it's very hard but doable to notice when you're entering such territory with someone.
____
[1]: you might be smarter than your boss, you may be "right" technically
[2]: "friction" in the economic sense, which includes overhead in your code as well as overhead from meetings. What stands between idea and productive execution.
[3]: literally, larger than the technical, including all aspects of engineering, organization and market forces.
[4]: the product that which you seek to make, i.e. that people use. The "internal" side of the product is the organization and codes that make it, that support its continued existence.
[5]: in this case, we "abstract prematurely" when we presume to know a system better than their maintainers, or that our "outside looking in" "fresh" pair of eyes has all the answers already. There is often much more than the technical to consider.
Slight tangent. You know this idea of "feeling comfortable being wrong" in front of someone, that it's OK to say dumb stuff in front of people we trust. I think it enables us to just try, up to our limits (where we must fail a lot by definition, and also the only place where we make actual progress).
When you can build the kind of team that can transparently fail (thus collectively improve...), within that 'safe' tech space of 'engineers', where we know it's everybody just trying and the ethos is aligned with that (nerds may speak, fail, laugh, etc.), I think you've got a solid basis for any project, any company.
You sound like someone who builds that kind of environment. I wouldn't worry in that case; again, nerds will pick up the signs if you just speak your mind — hints like you saying "So I didn't know X, and then blablabla", or simply asking bluntly "what do you think of our choice to do X?" instead of defending it like OP's interviewer. ;-) In general, people who ask questions have to be prepared to hear the answer, that's how I operate personally. I would just temper the response based on what I actually do know of the situation.
I personally don't spend one minute thinking about mind games if the other person seems direct, transparent, honest, especially problem-solving mission-driven kinda mindset.