When I review someone else's code I occasionally have to harp on about basic things. Missing Javadoc, superflous code, superflous methods, lack of attention to thread safety, lack of comments documenting intent, or even lack of unit tests. And some of the programmers that make these mistakes are not people who just graduated -- some of the programmers that make these mistakes are relatively senior software engineers.
The above are what I see as basic skills. If you cannot produce code that checks the above boxes consistently, you should consider yourself a novice programmer and you must work harder to become a better programmer. I don't care if you have been programming for 1 year or 50 years.
I'm not going to speculate as to why many programmes habitually skimp on neatness, but I'll offer some observations.
The first, and most obvious observation is that neat code, in my experience, is more often correct. It has fewer bugs. Not always, but more often and by a good margin. When people make an effort to write code that is eminently tidy and understandable to other people, correctness seems to follow. And where there is correctness and simplicity, consistent speed often follows.
I am not sure if this is because tidy programmers are inherently better programmers or because tidiness makes correctness more attainable. But they tend to co-occur.
The second observation is that code produced by messy programmers will be treated with distrust.
When we have to deal with code we do not understand we grow wary. It is extremely uncomfortable to put trust in what you do not understand. And it is even more scary to alter or to be responsible for changes to code that is hard to grasp. You do not want to build your system on top of code you do not trust.
Code that is not trusted is replaced. It doesn't matter if the code is brand new (although sometimes newness can lead to indecision in throwing the code away). I've seen people spend months of their life writing code which is then discarded because it was more costly to maintain and develop it than to start over. Or more importantly: because the code did not provide a foundation on top of which others could build. I know of no engineering discipline where so much work is simply thrown away on a regular basis.
It breaks my heart that a good proportion of programmers who have just produced code that is thrown away learn nothing from the experience and go on to repeat their mistakes.
Occasionally people will challenge me on the importance of neatness. They will point out that neatness is not a goal in itself. That it is the features, the performance, and not least moving projects forward that counts.
In particular the last argument can be hard to argue with. In particular when combined with lack of experience or lacking ability to extract learning from experience and mixed in with various popular project management philosophies like the focus on "minimum viable product".
Most software projects, if successful, will be long-lived projects. What you can do in the short term isn't really that interesting. What is interesting is what you can do long term -- how long you can maintain forceful forward momentum.
It is important to not knowingly make too many mistakes early on that will necessitate doing a lot of work over if your product or project is successful. Try to see it from an external point of view. How would you feel, as an investor if I showed you something, you invested in it and then I threw it away saying "of course, what you just saw would never work so I am going to throw it away and build something entirely different". That happens every day in the software industry. But we don't always admit it.
Software projects have a tendency to stagnate over time. Complexity grows, faults and design problems accumulate and at some point everything grinds to a halt. Focusing only on short term results without having a realistic vision of how to maintain developer speed in the long term means you will have to throw more code away earlier or you will have to suffer low productivity.
(To put numbers to the above: in my experience, projects that are messy tend to reach the point where more effort is spent on debugging and keeping the code afloat than on development after 3-4 months. However, killing off these projects can sometimes take years, depending on the size of the project owner's cojones)
Neatness may not be a goal in itself, but it is what is called a "keystone habit": habit that has a ripple-effect on everything around it. It is a prerequisite for writing good code. If you can't even produce neat code, it is highly doubtful that you are capable of paying much attention to more glamorous things like algorithm design, optimization etc.