Yeah I'm not 100% sure what the difference is, I'd love an elaboration. The languages you program FPGAs in typically are in the class of hardware description languages (HDLs) - and IMO description and definition are interchangeable in this context.
When you're talking about software you're talking about issuing a series of commands that execute in certain ways that produce a desired result. While you may have threading to give the appearance of concurrency(or actual discrete cores/etc) it's still largely a serial operation(with pipelining under the hood but largely not exposed at a software level).
In contrast FPGAs, CPLDs and the like use as you said Hardware Description Languages. These languages are not about issuing a series of actions but instead describing a blueprint for construction of physical hardware units(via SRAM LUTs, ASIC lithography or the like). Many things that are common and expected as a part of software(looping, blocking, etc) are either anti-patterns to not available at all.
Asking someone who's familiar with software to write HDL is like asking a Civil Engineer to do the job of a Mechanical Engineer in designing the drivetrain of a car. Both are professional engineers but they have vastly different skills.
I've spent a fair time in both worlds(although more on the software side) and learning FPGAs was like hitting a brick wall for ~3 months until you realize you have to unlearn all you know about software and build up an understanding from the hardware side first. It's also probably why firmware engineers tend to write so much copy/paste code and software engineers tend to write code that uses an order of magnitude more resources than they actually need.
This always seemed like limitations of the commonly used HDLs. Both Verilog and VHDL are extremely verbose and do not really allow a lot of abstraction. Even stuff like "I want this module to have a $common_interface" is hard to impossible without just copy pasting the definitions (sure, there are C macros) every time.
Stuff like sync vs async latches, global resets, exact cycle count are things that are critical in HDLs but don't have matter much in software these days.
For SystemC I'm not a huge fan, the types if things you want to describe tend to get bolted on and many constructs just aren't synthesizeable. There's a huge impedence match between the two.
I definitely agree with you there's more to consider when writing for an FPGA but not much more so than let's say writing for a microcontroller where cycles (at least timing) matters. Or anything hard real-time for that matter.
Theoretically I could write any web service in a synthesizable subset of VHDL. Similarly, you could, in theory, compile down any C program into an FPGA bitstream, as both HDLs and C are Turing complete. It may not function efficiently as the right considerations probably haven't been made in your C code to make it easy to do well. I could even turn my C program into an ASIC but that's not the point. The fact that FPGAs are reprogrammable and their functionality is defined in code means they are as much software defined as as any microcontroller. That definition IMO doesn't stretch to ASICs as they are not reprogrammable, and the resulting HDL goes through a huge pipeline of vendor-specific tools to turn the result into silicon.
This is my opinion of course, and I would argue that an FPGA bitstream is equivalent to a ROM for a microcontroller - software that defines the digital electrical characteristics in response to stimuli. Seems that if the latter is defined by software so is the former.