You can get facade types for any JavaScript library using https://scalablytyped.org/docs/readme.html . If types exists in the library itself or in DefinitelyTyped, you can use them.
sbt is not mandatory. All the build tools commonly used in Scala projects support Scala.js. For example, Maven or Mill. That said, you cannot use `npm` directly to build Scala.js libraries, indeed. npm does not have the infrastructure to talk the incremental Scala compiler, which is a must for fast development cycle.
We're trying to get a bit closer to JS tooling, notably with better tutorials and tooling targeting the like of Vite. But at the core, there is Scala tooling involved.
I've been working with Scala.js for several years and I have no idea why JDG chose those four bullet points as important weaknesses of Scala.js. Those weaknesses seem overstated, they just aren't the things I had to ever worry about, even when I was new to Scala / Scala.js. Like, I'm not good at sbt in general, but I never had problems with Scala.js build setup, even when I started cross-publishing libraries for Scala and Scala.js
I've been a part-time Scala developer for a long time and have trouble choosing Scala.js for any frontend project because of SBT, missing type facades for npm packages and just other general friction of using a non-web-native language for frontend development.
I want to see Scala.js succeed but I feel unless some of the major adoption pain points are addressed (which JDG addressed recently[1] about the Scala ecosystem generally) it will continue to be an ultra-niche project.
[1] https://degoes.net/articles/scala-resurrection