I've written hobbyist-level Verilog for about 10 years. I'd still consider my understanding of the industry to be mid-level, even a little bit less than that. The more I learn, the more I realize I don't know about. YMMV.
I'm adverse to the going above the RTL/HDL level of languages. My main concern is that you're essentially compiling/transpiling/outputting to HDL from a completely different procedural top-down sequential programming language. These languages use a series of steps, where the CPU is executing the first line of code, the next line, the one following, and so on. You're not describing what hardware to instantiate or build, you're telling the CPU what to do step by step by step. There's some minor differences with how OOP relates, but it still closely mimics the fetch-decode-execution cycle of the underlying hardware. Sure C#/.NET or Java gets compiled down to some byte-code, run within some *VM, and then essentially converted to assembly language. The point is that you're going SAME-SAME during the whole process.
You have to understand digital design before you can start writing in HDLs. The hard part about using Verilog, from my experience, isn't the syntax problem of "How do I do xyz in Verilog?" but "What hardware am I trying to describe?" With full view and understanding of what happens to each of your modules during a clock tick. Sure, there's still an idea of "this set of code executes whenever this happens", but there's some serious problems regarding the simultaneous nature of hardware. Very little happens simultaneously in a CPU --- even though it may execute it fast enough for you to believe it's happening at the same time.