I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar.

Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.

I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.

and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries

i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use

For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports.

In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.