I've only spent about an hour going through this post and its predecessor. I'm a career software engineer, although I've been working very closely with a team of FPGA developers for the last couple of years.
HDL engineers have a very strong preference to see the types of all nets and registers clearly defined. The pain points are mostly in organizing and stitching together larger projects out of smaller modules. You see this reflected in common project structures, where leaf nodes are in straight VHDL or [System]Verilog but larger structures may be stitched together with TCL or some custom in-house tooling.
HDL replacement technologies have a tendency to throw out both the low-level language and the abstraction language. IMO this is in part because they are being built by software engineers who have a hard time with the low-level parts of the standard HDLs.
But its not the low-level parts (eg, process blocks, type system, and arithmetic expressions) that are busted. Its the organization and abstraction parts (eg, the module systems) that are busted. I know this sounds counter-intuitive, because as a Schemer I know you're used to building systems where its more or less the same abstraction "all the way down" using a general model of computation as the base. But the practicing hardware engineers I know don't care. They are fully aware of the message-passing model that backs the HDLs. To them that model is an obstacle to be overcome on the way to building circuits.
Caveat: my HDL colleagues are all from the US aerospace/defense sector. They are firmly on the side of preferring VHDL over [System]Verilog based on the former's strictness and explicit behavior. So my perspective and feedback is inherently biased in that direction.