A designer breaking the rules will generally enhance their work. A coder violating an architecture will often just create long-term technical debt, at the expense of some short-term gain. That is, they'll get their piece done faster, but leave in its wake a nasty problem for someone else. Of course that only applies if the architecture is reasonable and its rules are correct from an engineering standpoint. In practice, many of the 'coding rules' are too brittle for the circumstances, thus making things worse, not better.

The difference is that one change is done purely for the improvement of the aesthetics, while the other is done because of some fundamental disagreement about the underlying engineering principles. One change is done irrationally because it "feels" right, while the other is a disagreement on the nature of the rules (or a lack of understanding of the purpose of the rules). But there are rules (whether or not they've been articulated).

Usually when programmers "hack" things, they cause a raft of other problems in their wake. As software development progresses from an art, to a science and onto engineering, hopefully the desire to hack at things will diminish. We can actually reliably build complex systems, but only when we choose to think about the right way to do it, rather than just react to our environment. Personally I don't think good programmers "hack". They build. It's very different.