There are a lot of ways for good code to express bad abstractions. The abstraction could be inconsistent with other parts of the system, inconsistent with the c

There are a lot of ways for good code to express bad abstractions. The abstraction could be inconsistent with other parts of the system, inconsistent with the concepts it is meant to represent, inconsistent with its own observable behavior, inherently complex or hard to reason about, inconvenient to actually use, poorly suited to whatever people actually use it for... I've seen a lot of code that is perfectly clean and "well-organized" as code but organized into absolutely awful abstractions. None of that goes against your core point, I just think that seeing the code and its abstractions separately is an important perspective for understanding code design. On the flip side, it's also totally possible to have bad code but a good abstraction. Some of the best abstractions I've worked with have painful implementations, and it didn't impinge on the quality of the abstraction itself! Of course, the bad code made life a lot more painful for the people responsible for implementing and maintaining the abstraction, and I'm sure it required some real skill and experience to keep that from manifesting to users of the abstraction, but they managed it.