I think you'd be better served by looking at his CPAN area [1] where you'll find this ~9 year old module (among others) is nicely formatted and highly readable [2]
Given the author's reported experience I'm surprised there aren't more posts from him on the mailing list (http://altair.cs.oswego.edu/mailman/listinfo/concurrency-int...) where this library, and all the other juc changes, have been discussed for years.
I think, as you allude, that the primary issue is not technical but behavioral. In the area of healthcare I work in (nursing homes), quite a few organizations have their data hosted elsewhere. Sometimes it's through the vendor, sometimes it's with a third-party service. I don't see that big a leap of faith to Amazon from this.
I haven't tried. Our prospective customers often want to physically inspect our data center as part of their due diligence process, and I can't see how Amazon could accommodate that.
Medical dictation is a success for recognition, but it's important to remember that no such system can function by itself. Instead, they're often advertised as making the human transcriptionist's job easier -- reducing the number and type of fixes a human has to make when correcting the dictation results.
True for some patterns, but not all. Unit of Work, for example, is a useful abstraction no matter what framework or language you're using. (It's not a GoF pattern, but it was brought up in the OP.)
I agree that everything is leaky abstractions. The lesson I get from the idea is to assess the probability of leaks occurring and the risks they present when they do. Some of the ORM ones that the author mentions are pretty onerous.
[1] http://search.cpan.org/~chromatic/
[2] http://cpansearch.perl.org/src/CHROMATIC/Class-Roles-0.30/li...