Schema Binding is pretty specific, and not that common a concept. It's got it's uses, mainly in high-end performance-tuning, but I wouldn't consider that a pass/fail question on an interview.

Coding to avoid page splits can be critical in very high transactionality environments with extreme uptime requirements, but isn't usually critical outside of that situation. Again, not usually a pass/fail on the interview all by itself.

ACID is critical in most data designs, either as strict adherence or deliberately ignore it (NoSQL) for performance purposes. This one I'd consider more critical in terms of weighing a candidate for a DBA/database dev position. Not necessarily "get this right or don't call us and we won't be calling you", but definitely high-priority.

Judging by the questions, I'd guess they're dealing with a large, highly transactional OLTP system with very strict uptime needs. (Page splits mainly matter because they cause index fragmentation, either clustered or unclustered, and rebuilding indexes can cause downtime if not managed perfectly.) If that's the case, they might actually need those things.

Knowledge of b-tree structures is again mainly about extreme performance tuning.

If you're looking to hire someone to administer such a system, and the candidate is asking for top-of-scale compensation, I probably would expect/require knowledge of those things. They might be willing to overlook those if you nailed other questions quite well (it sounds like you did), or if you indicated adequate understanding of the concepts to learn their specific needs quickly and easily.

So, no, I wouldn't call it "dumb" to not know those things. They're somewhat essoteric, even in performance tuning specialties. But it might weigh against asking top-tier on compensation if they have specific needs on those things.

Even the ACID thing wouldn't constitute "dumb". Probably more like, "SQL Server usually handles that for me, and I haven't had to manually account for it recently enough to have the data at my fingertips". Even if you skip the other bits, I'd still recommend brushing up on that one.

Not saying it'll take it negative on the interview. No way for me to know that, of course. But it is something to take into account on it.

On the flip-side of that, you can also run into a company that has highly overrated ideas of their needs, and completely incorrect assessments of what constitutes a good interview question. I've had interviews like that. One spent 15-20 minutes grilling me on firewalls and DMZs, even after I indicated I didn't know much of anything about that beyond being able to define both terms, and also indicated that I wasn't sure what that had to do with a DBA's usual duties (I'm accustomed to network/security admins handling that kind of thing, not DBAs).