Modern browsers have built-in timezone support via window.Intl. It's actually pretty nice! One glaring omission in the spec: given (UTC instant, tzname), there is no clean way to get that offset for that timezone at that moment.
tzjs works around this omission. This saves a lot of bundle space. moment-timezone includes the whole tzdata dataset: https://bundlephobia.com/result?p=moment-timezone@0.5.21
Not supporting timezones is a valid design choice, but is so important and integral it should be the first item both mentioned by a library and used as criteria to decide whether it's a valid choice for those surveying libraries.
It's sort of like choosing a storage solution. Do you need persistent storage that can survive a reboot, or is something ephemeral that works only while powered good enough? Both have their places, but choosing the wrong one for your specific use case is usually very problematic.
It's not like the author can't have known this, moment.js without locales is listed right at the top on the moment.js home page (but left out of this list).
At a previous client, we only imported the locales they actually support, you don't need to import the whole lot of locales if you don't want to. When you don't need the whole lot, they're actually tiny.
Side-note, Chrome recently changed how it parsed dates breaking existing code (if you left the "z" off a ISO date), yes, that meant different browsers native date parsing wasn't consistent until recently. I forget exactly when it happened but I think it's was about a year or two ago. I think we ran into it because we were using .Net MVC which by default the serializers would spit out DateTime's without the Z and DateTimeOffsets with them. They changed it for newer versions.
Personally, working with future dates in the restaurant trade, the recent dogmatic approach to treating everything with ISO is frustrating. When humans say "meet at a restaurant on 27th Sept at 7pm" they don't, at all, mean it by timezone. A person in France doesn't want to see the booking show 27th Sept at 8pm. And storing it ISO is dangerous as timezones actually change.
Regarding local times, if it's always local, why worry about it? Just store it in "UTC" without conversion, with the understanding that it will never be converted. That's what the Postgres "timestamp without time zone" type essentially is.