I think the most important good one is that it takes "register" renaming seriously. Calls start with a belt that only contains the arguments, for example, and that's done through the magic of renaming. Loops do something similar (they are a lot like calls on the Mill).
I believe there were lots of important bad ones: explicit speculation (super interesting but unlikely to work well), separating memory mapping and memory protection, having "dirty" flags in the cache at the byte level (to minimize writebacks), two PCs moving in opposite directions, very "interesting" encoding, two encoding levels: a general encoding shared between all implementations and many implementation-specific encodings via an installer/converter/loader/JIT, novel protection hierarchy mechanism, backing the renaming mechanism with a more compact representation of older values that aren't likely to be reused soon, automatic spill/restore of that to/from memory, ...
They came up with an interesting compromise between exposed pipelines and guaranteed repeatable execution for loads ("drop the value from this load onto the belt in n cycles").
If you desperately want a high performance implementation that doesn't use out of order execution then the Mill has a lot of good ideas... but an out of order execution implementation is much safer and is not nearly as scary as people think (in terms of complexity, gate count, frequency loss). Mill does not seem to be easy to implement as OOO which means it would have to work as an architecture with only in-order implementations, which sounds like a guaranteed dead end for the future of the architecture.
Maybe you can have a decoder that runs ahead and converts everything to something that isn't so full of relative value references (like the loads) -- and then bolt that onto a fairly standard OOO engine?
https://www.sigarch.org/distance-based-isa-for-efficient-reg...