Static analysis is ignored by the article here, but the import syntax requires all imports to be explicit. You can `require(someVariable)` but you cannot `import thing from someVariable`, that syntax is entirely not allowed.
Similar to that is exports: the export syntax requires you to give static names for exports in a module. There is no `export [someVariable]` that can give a dynamic export name. The closest is `export default` which the import syntax treats as unnamed (and `(await import('module-name'))` calls `.default`). In CommonJS `module.exports[someVariable] = something` and worse `module.exports = { /* entirely dynamic object */ }` were extremely common.
That sort of import/export static analysis is used for JIT compiler optimizations at run time in the browsers. That sort of import/export static analysis is used for safe tree-shaking at build time. (Yes, you can treeshake CommonJS, but it is dangerous and makes few guarantees that the final bundle is consistent/correct.)
Yes, you can still dynamically `await import(someVariable)` but browsers don't optimize that in the same way (and bundlers don't treeshake that in the same way). That doesn't mean that it isn't very useful that the base case better supports static analysis and compiler optimizations and tree-shaking.