I feel like you've not seriously used each of them. Ghcjs is very interesting, but also very, very early. The ecosystem is tiny, the compiler produces huge and slow builds, the interop is tricky, the semantics imperfect. It may be a very long time before any of those are resolved, too! Compiling a lazy language to Javascript is no simple trick. Luite deserves all the praise in the world for getting it this far... but there's just a long way to go.
So, in the terms of this article, Ghcjs might be around the same place Scala.js was 2 years ago. In the mean time, Scala.js has taken off in a lot of ways. It's yet to be seen what will happen with Ghcjs.
Your hunch is correct, I have not really used either, I'm just generally interested. From a distance, they both appeared to be ambitious and somewhat immature. I'm curious about your comment regarding tricky interop and "imperfect semantics" of ghcjs, could you elaborate? Certainly laziness does make FFI harder, but I wouldn't call that a problem with the semantics.
Laziness doesn't just make FFI harder (although it does do that too) it also makes code generation harder and implies the need for a sophisticated runtime. All of this makes the generated code bigger, slower, and more opaque.
A strict language can just skip all of that so long as it's willing to live within the limitations of the Javascript model. Scala.js does that for the most part and ends up with both nice FFI and a minimal runtime.
I don't see being strict or lazy as being the main source of the size of the deployed code (especially as Ghcjs inherits an excellent strictness analyser from GHC). Scalajs would have to emulate many JVM characteristics and port many JDK classes. Then you have huge core Scala libraries like collections, which are far larger and more complex than the Haskell equivalents. You will have to back up your argument with numbers to convince me.
You also haven't elaborated on your comment about "imperfect semantics".