Certainly not on the downstream, but for the upstream I can understand the desire for something like fq_codel or sfq still if you have a busy upstream at times and want to be able to still use services that are latency sensitive (such as gaming or VoIP). It's not until you get to around 200Mbit and beyond that QoS starts to become increasingly unnecessary in my opinion. Of course, if you have a light to moderately used upstream a majority of the time then QoS probably isn't necessary.
One thing I learnt when tinkering with QoS, is whilst low latency is nice, high latency is still better than packet loss. The best QoS is one that drops the packets from low priority traffic, I found this difficult to do with fq_codel on the downstream, to me the downstream is 90% of problems, with the high use of CDN's now along side with multithreaded downloads on things like steam, its very easy to saturate your downstream and then be unable to stream whilst downloading.
So for me the benefit of FTTP aside from higher peak speeds is the ability to ditch downstream QoS, I dont want to be hitting my line cap on FTTP with a client, as that then naturally leaves a buffer to allow everything to work alongside each other.
In the older days of ADSL, this didnt seem to be a problem even though we had much lower line rates, lots of factors contributed to this.
1 - CDN's were not commonplace, e.g. windows updates came from a server in America, so the higher rtt made it harder to flood your line with packets.
2 - Multithreaded downloads were not common place either.
3 - Less aggressive congestion providers.
4 - Older OS like Windows XP, had fixed small receive buffers, I think it defaulted to 64k with a gigabit NIC, or 16k with a 100mbit NIC. Tweakers would enable RFC1323 to boost their download speeds in the XP days.