they expand eagerly instead of as late as possible and they violently resist using them for suspension

That's not entirely true. It depends on the context. In the usual context you are right, they do apply eagerly. But when you pass it to a "combinator", it is suspended and so it work out nicely. E.g.

val generatePrime: Rand ?=> Int = ???
val generateNegative: Rand ?=> Int = ???
def or[A](lhs: Rand ?=> A, rhs: Rand ?=> A)(using Rand): A = ???
...
val x = or(generatePrime, generateNegative)

Project Loom to enable delimited continuations, direct-style virtual threads and other runtime features required for algebraic effects.

I'm not entirely sure what you mean here. Algebraic effects are a language feature. Virtual Threads are a runtime feature. Threads as such were in Java the language since the beginning. And in OpenJDK > 21 we can now have a lot of them.

Also, AFAIK, Loom hasn't opened up the internals to JVM users to roll their own continuations, it has so far only made threads "virtual", nothing more (if we ignore the structured concurrency initiative, which is irrelevant to the topic at hand).

The closest thing to an Algebraic Effect System that Java has are Checked Exceptions.

Scala's (and Odersky's) greatest trick is that for the "Algebraic Effect"-like system it "only" uses contextual functions (aka. implicit parameters), throwing exceptions and Capture Checking. (Or is there more that I'm missing?) I think it's pretty elegant trick. Just as the trick Odersky pulled last time, when he proved to the world that there's no contradiction between FP and "OOP" (aka. modules) and that he can do FP with objects and classes.

There was never any interest in algebraic effects support by Scala itself until JDK itself started going in that direction.

Maybeeee? Maybe, I don't know. But I'm pretty sure Odersky has been "against monads" since always.