So, worth explaining (as I've told other folks here), my experience is in enterprise content management, usually building good ol' fashioned websites that are running on .net and getting content from a CMS. For the entirety of my career, I never ONCE worked with a CSS library. Every single one of my clients (who were on the Fortune 500 list, usually) had too unique of a design and too many different types of pages for us to bring in an external CSS library.

So, for that reason, when I wrote these guidelines internally some years ago, we weren't concerned in the least with what CSS libraries were doing because we didn't use them. We were concerned with consistency, more than anything

We went with camelCase because we liked that it was the same convention we followed in our JavaScript, AND it was easy to select stuff in the IDE.

Even WITH there being a VSCode extension, I still wouldn't change my reasoning because that kinda breaks the guidance of, "least disruptive to the team." I wouldn't want to have a project that required some IDE extension to keep teammates productive the way they want.

ALL THAT SAID, as I explained in the start of the guidelines, they are just that...guidelines. The goal is to be consistent and not have teammates present or future curse your name. So developers should really favor team cohesiveness over my opinions based on my specific experience.

Another advantage of camelCase is that classNames (https://github.com/JedWatson/classnames) works without quoting:

    // you have a variable isFoo
    <SomeComponent className={classNames({isFoo})} />

is a lot better than:

    // you have a variable isFoo
    <SomeComponent className={classNames({'is-foo': isFoo})} />

(also, I personally shorten `classNames` to `cn` because it's so universally useful)

Yep, it would be nice if HTML/XML/CSS/Javascript/YAML/JSON/SQL identifiers were all standardised as it's not uncommon to see all of them in the same project.