Refutation:

1. Even the significant whitespace in FORTRAN wouldn't have been so bad if programmers had been using colorizing editors back in the day. If the comment field were one color, the label field another, the continuation field a 3^rd... Few errors mistaking one field for another would've struck.
2. When programmers scribble pseudocode on a whiteboard, they indent, but they rarely use curly braces or begin/end or do/od or whatever. Why? Because indentation alone is quite sufficient for rapid communication.
3. It's harder (or was) to find a missing pair of curly braces than bad indentation
   • For example, consider these two before and after pictures, one pair in C and the other pair in Python. We're going from a single statement hung off a for loop, which doesn't need curly braces in C, to a pair of statements - and neglected to add the newly-required curly braces in the C version. In curly brace languages (specifically those that don't require curly braces for every command hung off a for loop), the indentation will actually mislead you into thinking things are fine. Meanwhile, the python version works just as intended:
     • Before:
       • C (fine):
         for (i=0; i<10; i++)
         printf("%d\n", a[i] * 2;
       • Python (fine):
         for i in range(10):
         print(a[i] * 2)
     • After:
       • C (broken: indentation does not reflect reality):
         for (i=0; i<10; i++)
         printf("%d\n", a[i] * 2;
         a[i]++;
       • Python (fine):
         for i in range(10):
         print(a[i] * 2)
         a[i] += 1
   • The reverse problem isn't much of a problem, because the compiler finds it for you. EG this code produces the following error:

     $ cat /tmp/t
     #!/usr/bin/python3
     
     def fn(x):
             x *= 2
        return x
     
     fn(4)
     
     dstromberg-desktop-dstromberg:~/public_html i486-pc-linux-gnu 25187 - above cmd done 2010 Fri Jan 01 11:14 AM
     
     $ /tmp/t
       File "/tmp/t", line 5
         return x
                ^
     IndentationError: unindent does not match any outer indentation level
     dstromberg-desktop-dstromberg:~/public_html i486-pc-linux-gnu 25187 - above cmd done 2010 Fri Jan 01 11:19 AM
     

4. Please note that I've written this HTML document using significant whitespace; you know what it means, most likely. Curly braces really wouldn't clarify things.
5. Too little significant whitespace can also be a problem:
   It's rarely mentioned that FORTRAN also had whitespace that wasn't significant enough. The canonical example of this, is the visual-but-not-semantic equivalence of the following two statements. The first is a FORTRAN "DO" loop, while the second is a FORTRAN assignment statement. Can you see the difference? The problem is that the blanks are to be treated as though they aren't there, and it can be difficult to tell a comma from a period in some fonts:
   • DO 10 I=1,10
   ...and:
   • DO 10 I=1.10
6. Other languages with significant whitespace:
   • IMO, the most interesting very high level languages have significant whitespace:
     • Haskell has both curly braces + semicolons, and Python-like whitespace-based scoping. However, no one uses the curly braces + semicolons, preferring the whitespace-based scoping
     • OCaml
   • And then there's this stalwart traditionalist that also has significant whitespace, but you don't hear many people complaining about that. It's not only parallelisable in definition, it is very parallel in all to nearly all implementations:
     • sh/ksh/bash, AKA "POSIX Shell"
   • There are others of course:
     • ABC
     • Boo
     • BuddyScript
     • Cobra
     • CoffeeScript
     • Curry
     • F# (similar to OCaml)
     • Genie
     • Groovy
     • Have appears to do both curly braces and offsides
     • ISWIM (purportedly "invented" the concept)
     • Kotlin
     • Miranda
     • Nim
     • Occam
     • Pliant
     • PROMAL
     • Ruby (it sounds like a genuine problem in Ruby)
     • Scala
     • Spin
     • XL
7. At times the complaint about significant whitespace comes from people who use Really Long Functions or Methods^TM. You've probably already guessed that Really Long Functions or Methods are best avoided. Also, you can use a folding text editor to deal with them more effectively than curly braces could.
8. This one, I can only partially refute. If you're automatically generating Python code, the indentation is sometimes a true pain, not just an excuse. However, an important class of automatically generated code is intended to be human readable; this code should be indented anyway. But automatically generated python code that's not intended to be human readable is an issue, and isn't exactly an achilles heel.
9. Another I can only partially refute: If you're having an e-mail discussion about code, some mailers like to reformat your code into a paragraph. Needless to say, this is bad for pretty much all code, but pathological for Python and other languages that use whitespace in a manner distinct from basic paragraph-filling.

   Some alternatives:

   • Use a proper code review tool instead - EG Rietveld.
   • Use a wiki instead - sometimes with a <source lang="python"> tag (EG, on Wikipedia).
   • Use HTML e-mail and a <pre> tag
     • Except this'll have problems with real <'s and >'s - which are common in Python and other languages.
     • You can pipe your Python through this sed command to deal with real <'s and >'s
       • sed -e 's/</\&lt;/g' -e 's/>/\&gt;/g'
     • Note that this is no more onerous than running code through a code beautifier
   • Use a non-borken MUA like mutt for such communications
   • Mail your code as an attachment.

You can e-mail the author with questions or comments: