When would you actually create such tags as a fullstack dev? Almost never. 90% of the time, those tags are auto generated by some boiler plate app.
A person that can answer correctly MIGHT be someone that's looked into those tags and done things the hard way, but is that really someone you need to hire? A person that answers incorrectly doesn't necessarily seem like someone I wouldn't hire. After all, what do I care about someone knowing the intricate details of the "html" tag and how it interacts with various browsers? That's write once and forget sort of code.
If you wanted this test to mean anything, why are you picking worthless trivia. Why not, instead, pick something like a function out of jquery or your own code base and ask the same question "Tell me what this function is doing".
The point does not at all seem to be "Aha, gotcha! You didn't know about the syntax for Apple's limited PWA like functionality offhand in an interview. 5 demerits, next question!".
A person that can hold a good discussion around these tags is both likely to be one that has truly been developing pages for a couple of years and has an interest in learning more than how to make their framework work rather how to make any framework work in a browser. If you're not able to say something cursory about language attributes I'm going to have a hard time believing you've full-stacked a multi-language website (not that I wouldn't but it'd lead to a lot of different questions later). If your response about the doctype line is "it's boilerplate put in by my IDE" my first thought isn't going to be "oh they just spend a lot of time writing code in the rest of the page" it's going to be "they either don't care what the first line of the page is about or it's been so long since they've touch the front end directly they can't say anything about the first tag. I wonder how well they can deal with integrating the front end JS with the page" and steer to towards more about that.
Also the interview was mentioned to be an hour long, if 10 lines of HTML boilerplate, most of which should be on every page, is too far into the weeds of front end time wise then I'd have severe concerns the candidate would be too back-end heavy. Yes, other things should be talked about too, that's why the interview is an hour and this singular question is only about 10 lines.
Well, that's a problem. If you don't know how to create a web page with out having to fall back to using "some boiler plate app", I question if you really are a fullstack developer (I would also question if you really can consider yourself a web developer at all, but I know that will just upset people, so I won't go there).
This is the equivalent of interviewing for a C developer by letting him explain a Makefile.
It's that the signal you're gonna get out of such an interview is gonna be so low that whoever you end up hiring is mostly going to be due to chance + how much you "liked" them.
What if that C++ dev primarily uses visual C++ and Visual studios projects? What if the C++ dev primarily used Cmake, ninja, or scion (or any of the other thousands of C++ build tools).
What if that C++ dev never really needed to start a project from scratch?
The issue is testing someone on minutia doesn't tell you anything about how capable they are. In particular, testing them on minutia that they very likely rarely interact with is beyond pointless.
Then it's an opportunity for the candidate to explain the tools they do use.
There are certainly bad interviewers out there who misuse these kinds of questions, but I think they're fine if used as conversation starters.
But to the point, I'm not sure if the code at issue would be considered minutiae or not, but I believe that the more curious you are, the more you tend to dig into the details, and a person doing this over many years would attain a rich knowledge-base spanning depth and breadth. I know as a java developer that I've referred innumerable times the docs for the POM and settings structure in order to explore the limits of customizing my build, which would include the rather obscure features. Not saying this is technically comparable to meta tags in html, but maybe that's what the author was going for.
-- Robert A. Heinlein