The thing that HFSC does which HTB and layer_cake don't do is it decouples control of latency and bandwidth as two separate controls. Furthermore it offers hard-ish real-time guarantees on latency. So, by putting my voice packets into a real-time queue capable of using a hundreds of megabits for up to 5ms, I ensure that even with potentially tens of simultaneously queued voice packets (say for 5 or 10 simultaneous phone calls) the voice queue will drain completely within 1/4 of the inter-packet generation time (20ms) before any other traffic goes at all. Typically this is NOT what HTB does, as it guarantees a certain minimum bandwidth to each of its classes. I want complete starvation of everything until the voice queue is drained (or 5ms passes). It works GREAT for voice.
Then, within the link-sharing classes that regular traffic goes in, again I can control latency and bandwidth separately. So for example when a video stream starts it gets tens of megabits for 100ms to fill buffers, and will make other classes wait.... the problem with cake's basic per-user fairness is... I don't want fairness, I want certain things to get sent quickly and other things to wait, and I know which things, and I know the latency performance that I want each class to have. HFSC does that. It lets you control latency precisely and mathematically.
Furthermore I use an ipv6 only LAN network (except a few legacy devices) and I don't know if cake's per-ip fairness does anything at all for ipv6 but I definitely don't want it doing per-ip fairness between my voice ATA and some legacy android based video streaming device for example.
Let's put it this way, until I understood HFSC and set it up, which was just in the last few months, even a custom HTB system didn't give me the voice performance I wanted. Now: flawless voice.