Very true. They often are. But I just don't live my life blindly. I don't see the point in living life by the book without questioning it. But the matter at hand can't be tested XD That's why I stated that it's not science. There's no measurement for success. There's no performance increment to look at. If you can't test it, isn't it an opinion? If someone tells you that the sky is green what if they really see it as such? There's no way to prove them otherwise but by collective "opinion".
"You can't grantstand on "fighting the established order of things" without nodding to the fact that many of the "rigid" standards have already weathered generations of cynicism, scrutiny, and testing through application. You also have to accept that the answer to "questioning those before us" is sometimes "well, yes, they WERE right.""
It's one thing to question things, and honestly you are entirely within your right to say "Well, I know I'm violating established practice, but it hasn't blown up in my face yet, so I'm fine with it." however, composition vs. inheritance, and the appropriate use of such, is well established in the computer science community. As I stated earlier, LSP and SRP have been vetted by hundreds of smart people over the past 30-40 years -- you may not see the difference adhering to these principles make in small projects, but in large projects which change and have to be maintained and extended over time, you will rue the day you chose inheritance over composition when it was not warranted.
You charge that the benefit is immeasurable and therefore opinion -- false on both accounts. While hard numbers like performance or binary measurements like "well, did it work in the end" don't seem to indicate a difference, and "source code quality" might seem far too subjective to be a useful measure, I would argue that the latter is not as subjective as it seems, and indeed at least as useful a measure as the former.
Let us assume that there exists a group of very smart computer scientists, and let us assume that they have written a great deal of software, much of it medium or large-scale. Let us also assume that they have an academic and professional interest in developing the best methods possible, and that originating said methods is incentively (prestige, better jobs). Now let us assume that these people, having gotten together to share their experiences noticed certain patterns across their independently-developed projects. They talk about what works and where their individual solutions fall flat, and over time they co-develop a solution to a particular problem that seems to have the greatest benefit and the least amount of headache in aggregate. This is what a Design Pattern is (keeping in mind that a pattern is just an idea to be applied, not a thing to be applied.), this is what idioms are, this is what stands behind "theories" like LSP, SRP and innumerable others.
What you seem to insist on arguing, is that your one opinion, based on your own limited experience, should call into question the collective work of literally thousands of man-years of insight on these topics. If that's what you want to *do* then fine, go do so -- I'm confident enough in these assertions to say that, without question, your casting aside of these principles will one day make your programming life more difficult than it need be. But I would be remiss as a member of this community and as something of a computer scientist myself, if I did not counter such wild claims. You offered a solution that works, I offered one which "is better" -- and I can't point you to a chart or statistics, only to the collective experience of hundreds of minds greater than my own, or your own. If you want to take those odds on, so be it, but to recommend following suit is negligent.