If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?

They don't. I'm currently working on a code base created by "quick and dirty" programmers who would "clean it up later." They're long gone, and the code lives on, creaking its way toward oblivion.  Cowboy coders, in general, simply don't understand all of the potential failure modes that their software may have, and don't understand the risks to which they are exposing the company (and clients).