I think it’s going a bit too far saying that Loom will obviate the need for Futures. One of their main use-cases, that is improving a program’s performance with the help of asynchronous programming, will become obsolete - that’s true.
However, Futures are useful in another dimension, as a programming model. Having a “typed handle to a computation running in the background” allows one to express solutions to some problems in a much nicer, more readable, and hence maintainable way.
With Loom, the implementation of a Future might change, as @jdegoes suggests. But for a user, does it really matter if inside there’s a VirtualThread, or a Promise to be completed asynchronously? Probably not that much. As a user, you want specific functionalities. One big change with Loom is that blocking on a Future won’t be considered a mistake or bad style anymore - it will just be a bridge between the wrapped and direct programming models.
I’ve been interested in this topic for a long time now, so it’s very informative to see these discussions! 
By the way - time and again, people in both this and the original thread, as well as in various Loom presentations and discussions, keep introducing various notions of “computation handles”. Even here, in the JEP 428 snippet, we’ve seen Callable<T>, which is a lazily computation reference. We’ve also seen references to () => A or () => Try<A>, not to mentions the Future just discussed.
I think it shows that ultimately we do need a way to represent a computation as a value. FP has shown that lazily-evaluated computations have better characteristic (again, from a purely programming model point of view) than eager ones.
In the end I think that’s it’s better to have a single datatype (even if it’s sometimes too powerful), rather than endlessly convert between Futures, lazy Futures, Callables, Runnables, homegrown () => Try[T] etc. Yes - that single datatype resembles the IOs that we know today.
But just as Future.get bridges the wrapped and direct programming models, can we bridge IO and direct? So that we can program in both styles, depending on our needs? In a way, that keeps the interruption semantics and properly propagates fiber/thread-locals?