because they are assuming the reader has already built a query engine and is now re-writing it.
first prototype: bottom-up design
second pass: top-down design
first prototype: bottom-up design
second pass: top-down design
Imagine you get IKEA assembly instructions for a chair. There might be a few valid ways to start assembling a chair. There will be also ways that make chair assembly impossible. It makes perfect sense in that context to tell you "what the first step should be".
I don't see any reason for starting with type system in making a query engine. Things that come to mind as a better first step: select data constructor, or select paradigm imperative vs declarative. Maybe select the level of data consistency you aim for... maybe choose whether querying should be mostly interactive vs mostly non-interactive. There are tons of other decisions to make.
This "let's start with types" feels like that Star Wars moment where Vader randomly points at some spot through the cockpit window and tells the captain to head that way. And once the captain enquirers as to the reason this particular direction was chosen, Vader gives some vague answer like "why would you go anywhere else?"
I.e. ask yourself: would I not able to start working if my type system didn't have a 16-bit integers? Why would I care in my design if the system had or hadn't 16-bit integers?
And, if you are honest, the answer to this: no, nobody cares. Plenty of important design decisions don't require this information at all. In fact, the sizes of integers may never even appear in your query system (eg. all you deal is are byte strings), and it would still work...