This is because of how the FPGA toolchain works. There are several main steps: synthesis, mapping, placement, and routing. Synthesis is the only one that is similar to compilation. Synthesis is also the only step that is easiest to parallelize (each module can be synthesized independently of the other modules) and as a result it is usually only a small part of the overall time it takes to run the tools. You can kind-of, sort-of compare mapping, placement, and routing to linking as these tasks work on the complete design. However, linking is basically a trivial operation that mainly involves reading in all of the object code from the compiler, fixing up a few addresses, and writing out the executable file. Every time you re-run your software tools, only a few files might need to be recompiled, but the whole output file will need to be re-linked. But this is fast because the linker isn't doing anything particularly complicated.
Mapping, placement, and routing, on the other hand, are highly computationally intensive, cannot be easily parallelized, and they are also highly non-trivial to do incrementally. Mapping takes a 'high-level' netlist from synthesis (AND gates, OR gates, muxes, flip-flops, adders, etc.) and converts it to device primitives (LUTs, flip-flops, carry-chains, etc.). Placement then decides where to place each primitive on the device, and routing figures out how to route all of the connections using the interconnect network. And all of this is timing-driven - the tools attempt to map, place, and route all of the logic such that all of the timing constraints are met. It is a vastly more complex problem than simply converting a bunch of C into a bunch of assembly.
Doing this incrementally means keeping track of what your change at the HDL level results in in the final routed design. This is highly non-trivial to do, and pretty much impossible to do well. The tools basically need to compare the old synthesized netlist with the new one, propagate the changes down, and hope that things will work out in the end and the timing constraints can be met.
I have some personal experience with incremental build going wrong. Recently, I had to delete and recreate an Intel FPGA project when it refused to re-place a particular register after changing some timing constraints, as the incremental build thought that since the logic that generated that register did not change, the register didn't have to be moved. This was after wasting several hours trying various combinations of obscure directives to try to get the tools to cooperate before I realized what the problem actually was.