I think this commits the same sin many other new HDLs do -- it just tries to awkwardly smush the paradigm of clocked logic into a sequential software language. The abstractions just don't match, which means you lose the mental connection between the code and the generated Verilog, which makes debugging stuff like timing awkward.

I'm a big Bluespec booster, and beyond the nice typing and functional programming you get I think the big advance it brings to the table is the Guarded Atomic Action paradigm, which simplifies reasoning about what the code is doing and means that it's usually not too painful to poke at the generated HDL too since there's a clear connection between the two halves. At $WORK$ we've been using Bluespec very successfully in a small team to quickly iterate on hardware designs.

I don't want to denigrate the Spade developers since it's clearly a labor of love and nicely done, but I feel that unless the underlying mental model changes there's not much benefit to any of these neo-HDLs compared to SV or VHDL.

Spade author here! The biggest difference is that BlueSpec uses a different abstraction than standard "RTL". That has significant advantages of course, but also means some overhead and a shift in mental model.

With Spade my goal is to build new abstractions on top of RTL. That should allow you to operate at a higher abstraction level with minimal overhead most of the time, and dive down to regular RTL when necessary