Sure, if you just try to write software and expect it to work as hardware you're going to have a bad time, but that's not really the point of these tools.

The reason to use a programming language for hardware design is that modern programming languages are monumentally better at abstraction than pretty much any available HDL or hardware design tools.

However those abstractions rarely map to hardware well.

For example, I use hash maps and vectors for almost all of the adhoc data structures in my programs. Neither of these have a useful abstraction in hardware.

At that point, why am I using a modern programming language?

Again, those are software concepts. That's not what I'm talking about.

The point is, there are many hardware level constructions (FIFOs, BRAMs, CAMs, etc.) which can be very usefully abstracted.

And you use a software language to do it, simply because the hardware languages are so bad at it. There's no reason a HDL couldn't be good at expressing these abstractions (indeed Bluespec exists and does a fairly good job), but since they don't, using a programming language simply as a metalanguage is still better than actual HDLs.

And of those that map to implementations, many are physically infeasible implementations

And the designs that are feasibly synthesizable usually have to be tweaked until the timing works out, which gets harder the faster your clock speed and the more different clock/power domains you have.

There's a significant risk that any high level abstraction would be leaky enough that you might have to rip up large parts of the design and start from scratch with Verilog/HDL anyway.