Here's the thing about landmark roles. They are what the ARIA spec calls weak roles, in that they don't change the role that is exposed through accessibility APIs for an element. So, a div with a landmark role remains a div, and an AccessibleAttribute, a collection of all kinds of information that doesn't fit elsewhere, called xml-roles, is added. So screen readers look at the attribute array for each accessible, and if they find the xml-role to be one they know as a landmark role, they expose the landmark information.
These landmark roles were conceived before the HTML5 elements header, footer, main etc. So when these were invented, and it was clear that these bear a close resemblance to the landmark concept, they also receive the xml-role attribute, like "banner" for a header. But here's the catch: This mapping only happens under certain circumstances, not unconditionally, like ARIA roles. So a header only get mapped to banner if it is a direct descendant of body, and not inside a section, for example. Moreover, header, footer etc. get their own exposure in accessibility APIs, since these are also used in epub and other contexts. To also expose them with an xml-role that corresponds to the landmark specification, just makes it easier for screen readers to detect whether the element was intended as a landmark or not. These simply started to work as soon as browsers like Firefox started exposing them, screen readers didn't need to implement anything extra.
So, the roles you see in accessibility inspector are essentially correct, in that weak landmark roles don't influence the outcome in accessibility APIs, whereas a role "button" or "combobox" would change the semantics of the host language element, like a div.
What we could do, in theory, is indicate in the role display that this is a landmark, saving the developer the extra steps of having to look in the attributes sub tree for the xml-role value. Yura, Jamie, what do you think?