This is just a guess, but reading RFC 819 (https://tools.ietf.org/rfc/rfc819.txt), which transitioned ARPANET to a hierarchical naming scheme and also predates DNS, the little-endian notation might be a simple artifact of ARPANET's e-mail addressing. E-mail addressing was already user@host, which is basically little-endian. It would be consistent to extend it like user@host.site.network. JANET also used @ notation, but used big-endian notation for the domain, which seems inconsistent, at least from a user's perspective.
Wikipedia says JANET's e-mail addressing notation was defined by the "Grey Book", and this Usenet thread, http://neil.franklin.ch/Usenet/alt.folklore.computers/200209..., says the Grey Book domain notation comes from the Network Independent File Transfer Protocol (NIFTP aka "Blue Book", which was a different protocol from ARPANET's RFC 354 FTP). This 1990 JANET<->ARPANET e-mail gateway document, http://dotat.at/tmp/JANET-Mail-Gateways.pdf, says that JANET e-mail was transferred using NIFTP, so it would make sense that the domain part of the e-mail address would use NIFTP rules. Both above sources say (explicitly or impliedly) that JANET generally, and NIFTP specifically, were based on X.25, and X.25 uses big-endian addressing.
So on JANET the hierarchical naming scheme predated the e-mail addressing scheme[1], whereas on ARPANET the reverse is true. Both formats make sense as path dependent outcomes.
[1] Presumably JANET still adopted user@ because the message format was based on RFC 822, according to that gateway document above, but it was still worth partially deviating from RFC 822, which explicitly defines little-endian domain syntax, because of JANET's pre-existing host addressing scheme.
I am still waiting for an apology for mathematics and base 10 numbers being written the wrong way round logically!
Same with SQL. I am giving SQL trainings this year, and I have to explain why the server will read your query in a completely different order than how you write it.
Numbers are written correctly, most significant digit on the left. SQL is mostly correct according that logic, first `join` then `where` then `order by`. There are inconsistencies though.
You are used to see the most significant digit on the left, but really we have to right align a column of number in order for them to be readable, whereas everything else we read is left aligned. And you don't know what this significant number corresponds to (thousands, millions, billions?) until you have read all the other numbers (if you read left to right).
As for SQL, you write
SELECT TOP 10 ColName FROM TableName WHERE X = 10 ORDER BY ColName
and the server reads
FROM TableName WHERE X = 10 SELECT ColName ORDER BY ColName TOP 10
It is not "mostly" the right order.
And right to left assignment for mathematics or programming.
I suppose an enterprising browser hacker could implement this such that the browser could accept URLs in this format and reorient them when it makes the requests. Even paths would be tab-completable from browser history, would they not? I would love this in my browser.
That's actually how addresses are written in Chinese -- most general to most specific. Super disorienting when you're learning it as an English native speaker.
[0] https://en.wikipedia.org/wiki/JANET_NRS