That doesn't actually prevent the issue with the debuff cap FYI.
Printable View
It was a UI compromise that was only a problem due to class design. A limit of 48 visible debuffs isn't a problem when each player can only apply 1 or 2 stacking debuffs/dots. It becomes a problem when each class applies 3 or more.
That didn't actually do anything (as that option is a client side culling) when the server was not sending you the info on your debuffs/dots. The server only sent out the info on about 48 buffs/debuffs/dots per target (to save on memory use/packet size) while only tracking up to about 100.
Most dots (Save SMN) are just a single DoT at this point so I say yes.
And the solution to that should be to give a clientside priority to show your dots before even trying to show the rest of the raid's. User's dots = Boss's buffs > trick attack = chain strategium = feint = addle = slow = blind = bind = stun = paralysis > other player's dots. The fact that the game puts every status effect into a bucket and just splashes whatever gets applied first onto those two rows is definitely a ui issue.
I agree some dots are just skill fodder (looking at you Sonic Break) but I disagree to remove all of them. SMN and BRD are dot management most notable BRD since I can’t imagine then reworking jobs to remove features.
The UI pretty much does that as the client parses your debuff/dots and the target's buffs/debuffs to take priority to visualize. The client can not display any info that it doesn't receive. The problem was that the server wasn't and doesn't send the full list of all buffs/debuffs/dots if it exceeds a certain limit. The server only sends you something like the first 48 buffs/debuffs/dots on the target even when it actually has 49+ buffs/debuffs/dots on it. If your debuff/dot ends up in position 49+ on the list no one is seeing it.