I don't doubt it. But I'm willing to bet the majority of Live's users don't rate this issue as highly. & why would they? Most of them are still using Live as a live application. It's only the people trying to use it a post production DAW that the automation pdc "bug" find a "huge" issue with it.
I mean he's got a video where he goes from 20 bpm to 480 bpm to demonstrate the issue. I can see how that can really put the brakes on a project.
I made a simple test for the sends latency that is not compensated by live: a simple snare loop with a short room reverb on a send. First render at 1024 buffer size. The sound was like bom-kah. Then 512: bokah, then at 128: Kahh!
Its better the smaller the buffer size. Not everyone knows this. And if like me with not new cpu and big projects I usually have to work in 1024. Rendering the project I put buffer size as short as I can before live crashes. For me the limit is 128. But if would be nice to not have to move back and forth in the setings like this. Many times it happens that I forget to put it back after a render lets say in the night. Then next time I open a project and live will crash. Then I have to load an empty project and reset the buffer size.
Also there are measured some latency issues with racks. like if you make a crosover and you have a plug with bad latency in one part, the crossover will get out of phaze because of the latency difference, creating a static flanger sound.
50% of the producers I talk to that dont use live usually asks about lives audio quality because they have herd its bad.. This roumour comes from PDC I would guess..