Speaking from my experience, I've found that it is a balance. Starting a new project and molding the architecture as you go is more difficult than maintaining an existing project. With new projects, you have a blank slate of sorts and it's up to you to define how it is structured. Existing projects already have this defined and give you some constraints to work under, limiting your choices and, because of this, potentially giving you a quicker time to implement.
I would say it is unfair to compare your personal projects to your professional projects. Personal projects are your projects and you should use them as an opportunity to objectively try new methodologies and technology. That is, unless you're writing the project purely for the functionality, in which case - why would you place more weight on the design versus the functionality?
With respect to UML diagrams, I've not had any experience in using them for project design. I tend to think that they are a bit heavy handed when the company considers the most important thing is to ship code. Because of this, I tend to start coding at a high level after giving it some thought to the approach of what I want the final product to look like. I consider maintainability and readability to be the most important factors at this point. Another problem with the documentation is that it has to be read to be useful. You could sketch a UML diagram to help you think through design, but even if you package up all of your documentation later, will anyone actually read it? Unread documentation is not useful.
Regarding the "code, refactor, code, refactor" cycle, you only need to do this when you need to improve the code. Avoid refactoring for the sake of refactoring. Take the approach that you are making necessary improvements to the architecture. I usually do minor refactoring (extract to method, naming conventions, etc) and leave major refactoring (architecture, class structure) to the times when I'm enhancing the system or fixing a particularly nasty bug that seems to be the byproduct of the design (or lack of it). I have seen many places that would benefit from refactoring, but if the function is working, I don't mess with it unless I think it's necessary. In the short term, I will still make the minor refactoring adjustments just so I know things are improving.
At work, I try to keep in mind to "leave things better than you found them." This doesn't mean I'm continually refactoring code with every change, but that if I am making a change that is significant enough to warrant an evaluation of making it better, I consider the options (also weighing in the amount of time it would take to implement along with risk, maintainability, etc) and choose the best bang-for-the-buck option.
Part of the advantage of working on a team producing applications is that you get exposed to alternative methods of design. You also are made aware of obvious short-cuts in design or implementation to get it out the door. The consistent example I come across is the lack of use of polymorphism versus the use of variables to control behavior. The former takes a little more effort to implement and is usually more maintainable and less prone to weird behavior. The developer may have thought that (s)he was just reusing the code that is already there, but the long term maintenance weight that carries is not always insignificant.
Regarding commercial project deadlines, there are many variables. Not all projects are on a death march, although it seems to be fairly common to value the shipping of code over its quality. End users do not care about any fancy designs you may have implemented, much less your choice of dependency injection container. They are more concerned with well performing, accurate, and reliable software that gets the job done.