You're welcome to disagree of course, I held a somewhat similar view to you until I tried BEM in a production setting.
And of course, different products call for differing methodologies. I haven't yet switched my personal blog over to BEM, for example.
My experience and all the data I've gathered about performance, even coding the equivalent in UCSS was shocking: 400% render speed improvement. 600% loading resources improvements and radical painting speed. To set you in context: one corporate website from a bank, had an average of 230kb resource loading, we lowered it to 33ms. 650ms rendering, we lowered to 90ms. Painting speed avged 90ms, we lowered to 12ms. If you plan things properly, you can radically improve the speed.
It's true that UCSS doesn't make that much sense for very small websites. Although you will render close to a plain HTML doc for sure. It makes sense when you need to repeat and componetize many things. There's when you gain true power. For example, in our tests, we made another equivalent 590kb uncompressed CSS file to 32kb total code need in UCSS. Compressed was about 12kb against 190kb compressed file. That's how you make great improvements.
If a human isn't going to read the CSS and the computer handles it without performance problem, I say no.
Those are of course two quite important ifs!
First, not all users need your huge CSS file, in terms of downloading. Specially when they're on mobile phones and cache is crap.
A ~9000 rules CSS file will load and become COSSM slower than one that has 1000 or 10. It is linear increment. Make a test to see it for yourself.
A bloated CSS is more network time. Therefore, slower loading.
A bloated CSS will contain slower selectors, therefore slower rendering time and painting speed.
When you count all these things, you will see radical speed performance.
Rule 1 of performance: Your intuitions are not reliable.
