Yes of course, but it's the business need that should drive that discussion, not the DB architecture. "I'm not putting X in my database" is very different than "Well, if we need to do Y, I think we'll have to change A, B & C". Up to others to decided if it is worth it or not.

It's also completely reasonable to say "We shouldn't do Y". The response to everything shouldn't be to go immediately into solution space and list off trade-offs on the assumption that Y is happening. With people you trust for both their integrity and their expertise, "we shouldn't do Y" is a reasonable shorthand for "there are a pile of valid reasons we shouldn't do Y, and you and I both know I can list them for you off the top of my head, and it might well be possible anyway but it would take a lot more work and trade-offs than you might expect".

That isn't the end of the conversation; if the response to "we shouldn't do Y" is "it'll be a pain if we can't do Y", then you can explore solution space together, where that solution space includes both trade-offs to support doing Y and alternatives to doing Y. Use experts for their expertise, rather than the equivalent of "I don't care, make it happen".

Or, in short: yes, of course the DBA doesn't unilaterally dictate the architecture, but maybe listen to their expertise anyway.

As far as I can tell, we are agreeing.

You should also consider that that was a loose, humorous description of what happened, and not something really worth analysing to the last letter.

Fair. I have multiple times run into that attitude seriously, otoh.