This philosophy is similar to Python 3's hard separation of bytes and strings. Bytes are raw data you get off the wire and which are encoded in a certain way. Once decoded into a string, you have a clean, consistent internal representation that behaves as you expect a string would. If you're juggling (or even thinking about) byte encodings past the parsing stage and before the output stage, you've done something wrong.
Yeah, it generalizes to an argument for using types to encode assumptions about data, so you have static certainty/remove dynamic uncertainty. I'm strongly in favor of all arguments that let me remove sources of uncertainty from my mental model, since enough stuff I'm uncertain about always remains.
I think this is also the main point of the post you linked: the "bad" example has a numeric value and then performs byte swapping on it, the "good" examples only ever construct "correctly ordered" numeric values.
If you can possibly get to a place where you have a uint16 but the value is "in the wrong byte order", you've done something wrong already.
Admitting the possibility of values with the wrong byte order into your system casts every single value into doubt. Of course it's possible to resolve that doubt on a case-by-case basis by carefully identifying the right places to insert ntohs()/htons() calls, but to me that sounds like creating extra chores for yourself while working against the language.