I like the concept of code smell. It recalls the idea of identifying something that you dislike, but cannot tell exactly why. You don't have a good reason, but just a feeling that it's wrong.
I recently found a new type of code smell at work. One of my colleagues - a highly skilled developer who I respect and enjoy working with -, told me he was taking a concrete design decision pursuing that other programmers could not later misuse it. He was implementing a C++ class hierarchy and he wanted to prevent others to freely instantiate objects using operator new.
We discussed technical options to achieve what he wanted but I had a weird feeling during the conversation. In the end I recommended him to discard the idea and simply don't implement what I then called a bad programmer protection. I call it simply code protection now. Second thoughts on the matter led me to identify a twofold kind of code smell.
First, it is a pure technical smell in the sense that you are writing code in order to implement what is not a business requirement. One may argue here that proper code formatting is not a business requirement but accepted to be good practice. Code readability might not be a business requirement itself, but it is important for maintainability, and that is (or should) always be a business requirement.
The other side of the smell is organisational. Even if you implement your design in a way that makes it hard for others to misuse it, you cannot prevent others to rewrite it in a way that protection gets nullified or just removed. So it is an indicator that you doubt about your co-workers capability and good judgement.