I would take your point forward and say if the code is hard too read then is it shit.
There is a reason that you are reading it: you are maintaining it, adding a feature or trying to fix a bug. If it is not easy to read then it makes this harder and that makes code bad and increases the chances of the editor making a mistake and breaking the system. (Or just making your day bad).
Is it hard to read or hard to understand ? Generally when we say "hard to read" we mean both. Especially because as you said, you read the code for a purpose, and that purpose is very often business related rather than purely aesthetic.
Making the code easy to read is simply a technical matter, an intrinsic quality of the code. However, your code cannot be easier to understand than the business it models.
To convince yourself, have a look at some (good) framework like a HTTP Server, ORM, or browser, ... Their code is generally miles away from what you expect and hard to read if you do not dedicate days or weeks to them. But it is not due to bad code but due to the fact that you are aware of only a tiny fraction of the problem they solve.
EDIT: (I realise I didn't make a point) My point is that it is not a hard rule. If you are experimented with the business, familiar (a bit) with the code and it is still hard to read that is the sign of trouble.
For those of you who were commenting and looking for a local only timetracking , I have a git plugin that supports Redmine timetracking, and is git friendly. Also, works for gitbranches and git repos, tracks by repo/by branch or annotated tag - does some other stuff - got to stop adding random features.
three projects: Homenet a closed source home networking system, multimedia, it's own TV stack. Currently re-writing as i thought the networking was a bit weak, and the android remote control/EPG was UGLY!
There is a reason that you are reading it: you are maintaining it, adding a feature or trying to fix a bug. If it is not easy to read then it makes this harder and that makes code bad and increases the chances of the editor making a mistake and breaking the system. (Or just making your day bad).