The purpose of a principle is to be understood, and help us write better software with that understanding. The fact that SPR is so widely misunderstood, then, is a failure of SRP as a useful concept, not a failure of people misusing the term.

Ideally, you take a term or phrase like "single responsibility principle" and use it to discuss a particular design, interface, or implementation. If you can't do that, you have to find a different way to discuss your code.

It's like "clean code". Most people will agree that code should be "clean", but not come to any sort of agreement about what makes code "clean," or whether some specific code is "clean." The way to dig yourself out is to ban the word "clean" and ask people to explain things using different terms.

You've used one of my favorite phrases to describe code... "hard to read and understand". It is, of course, subjective. Alice may think it is easy to read and understand, Bob may think it is hard. However, it's easy enough to agree, in most cases, that everyone on the team should be able to understand the code. Therefore if I find the code hard to read and understand, that's a valid criticism of the code, even though it's a subjective criticism.

I can say, "This code is hard to understand because there's a bunch of color scheme information mixed in with the tax rate calculations." Or I can say, "This code is hard to understand because there are too many small functions." Honestly, just throw SRP in the garbage.