good for a one time action, not generally maintainable or provable ( only because they are generally written without much thought as to error recovery or unexpected input handling )

Speaking as someone who has written code and scripts for a living for over 35 years now.

I rarely see well-documented shell scripts.

There are exceptions to that. I wrote one to back up files to CDs, 'way back before DVDs. It contains full documentation -- name, license, where to get it, outline (I., II., III., etc., of process, variables, user prompts, checks, functions), and finishes with "# an added attraction for those who are not easily offended by bad ascii art" -- an ASCII flowchart.

I used that thing even after DVDs came along because the target maximum "iso" image was set by user input. Of course, hard drives became a cheaper backup media very near the same time as DVDs appeared.

Then there is the 44K bash script I wrote which is a prime example of your rule. Its purpose was to tie a conglomerated mess of a business data system together. They had a dos-based data entry system whose output had to be transmogrified to go into a postgresql database on a GNU/Linux system to produce monthly bills and reports. It worked for 6 years and was chock full of 'corner cases'. There are bits and pieces of it I might be able to explain now. It became a sort of Jenga -- edit only certain parts known not to break.

The Deep, Dark Secrets of Bash By Ben Okopnik
http://tldp.org/LDP/LG///////////issue55/okopnik.html

(Contains links to some more bashing by same author)