E. W. Djikstra, EWD952 
When we're talking about computer code, we humans say things like "Read in a line of text. If it ends in a newline, remove it." But we can't program computers that way. The compiler says, in effect, "Read in a line of text from where? And put it where? If it ends in a newline? If what ends in a newline?" And so on.
But Perl actually lets you program that way. Perl says, "Read in a line of text? You didn't say from where, so I'll assume the default place, which is the files that were named as arguments in the program invocation. You didn't say where to put it, so I'll put it in the default variable. If it ends in a newline? You didn't say if what ends in a newline, so I'll assume that you're talking about the default variable, which happens to contain the line we just read in." And so on.
Effectively, you can use "it" in your conversation with Perl, and it will do reasonable things. This is one of the places that it shows that Perl was designed by a linguist.
An example adapted from the Winograd Schema Challenge is:
The file couldn't fit on the hard drive because it was too big.
The file couldn't fit on the hard drive because it was too small.
In the first sentence, "it" refers to the file; in the second sentence, "it" refers to the hard drive. Native speakers who know what files and hard drives or (or even who don't) should have no trouble understanding the references and might not even have noticed that there was any ambiguity (!), even though resolving the ambiguity requires bringing to bear specific knowledge about the world.
There is a whole family of AI language understanding problems based around this, such as
Looking over some examples shows just how challenging this can be, because of the way the sentences can require people to know arbitrary things about the world. ("The atom emitted a photon because it was entering a lower energy state.")
Actually, in this example knowledge of the world (I'm interpreting this as referring to knowing the details of how "files" and "hard drives" relate to each other) is not necessary. The ambiguity disappears as soon as you know the meaning of "fit" -- fitting requires a large thing to contain a small thing. Therefore if something is too large, it must be the contained object, and if something is too small, it must be the container, and those roles are marked directly within the syntax of the sentence.
You can easily see this experimentally by asking people about sentences with nonsense words:
1. The glirp couldn't fit on the vell because it was too small.
2. The glirp couldn't fit on the vell because it was too big.
Then again, I see you've already noted that speakers who don't know what files or hard drives are should have no trouble with these sentences. Is the lexical meaning of "fit" "knowledge about the world" to you?
The melon could not fit on the hat because it was too small.
The melon could not fit on the hat because it was too big.
You can investigate this yourself at http://corpus.byu.edu/coca/ ; the first hundred results for "fit on" contain, by my eyeball estimate, more than 90 of the sense I describe, zero of the sense you insinuate, and a few spurious hits (such as "to spend as it sees fit on government services", "kept himself fit on a rowing machine", and my favorite, "I've worked with schools such as the Pratt Institute and FIT on developing eco-friendly vegan design programs").
There are six results, out of over 500 million words, for "fit it on", of which one matches your pattern. ("She passes it under the running tap and hikes her tank up to fit it [a strip of nylon] on around her rib cage")
or a similar kind of inference that could be considered easier than expected.
I'm not sure exactly what I would consider "knowledge about the world" in this setting. :-)
Situation 1: vell=table, glirp=dish. "It" refers to the vell.
Situation 2: vell=bolt, glirp=nut. "It" refers to the glirp.
Replace "on" with "in", and maybe there's less ambiguity.
If the goal of programming languages was to instruct the computer, after all, we'd be all writing machine code.
Way back, I'd designed a scheme-based scripting language called "muSE"  in which we created specifications for video editing styles. I also toyed with the language. One such experiment was having a way to refer to values already computed using "the" and "it". 
edit: This project isn't maintained, but the latest version 711 still works on macosx 
(open-file "blah" 'for-writing)
(write (the open-file) "hello world")
(length (list "milk" "pudding"))
(print "number of items is " (the length))
The paragraph that stuck out to me was: "Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve."
There's plenty of room for ambiguity or contradiction in programming, and good things happen on either end of the spectrum.
Start off with vague requirements from your client:
We need a machine which can wash clothes at various
temperatures and speeds. The user should have options
to control the temperature and speed since they'll have
different types of materials. Maybe we can give them
some preset options?
What are the temperature options?
Hot, warm and cold; but it's in two cycles and each can
have a different temperature.
How long should it wash the clothes for?
That depends on the material and how dirty it is.
What if it's really dirty?
They should be able to do an extra rinse cycle.
How fast should it spin?
That depends on the material and how dirty it is.
Dial presenting options for:
Buttons allowing further refinement:
Water: Hot/Cold, Warm/Warm, Warm/Cold, Cold/Cold
Extra Rinse: (yes or no)
"Dirtiness": light, normal, heavy (impacts wash duration)
Also, feels like Inform7 should be mentioned in any discussion on NLP and programming: http://inform7.com
First thing to mind based on the article's premise and hits a lot of the article's desired points already.
> If a language is designed so that you can "learn as you go", then the expectation is that everyone is learning, and that's okay.
It's okay if we never reach understanding or agreement on what Faulkner intended by a particular sentence (we can still grasp most of the whole). For a programming language this is explicitly not okay! This goes for ambiguity as well.
> Multiple ways to say the same thing
> This one is more of an anthropological feature. People not only learn as they go, but come from different backgrounds, and will learn a different subset of the language first.
This increases cognative load with no particular benefit.
With perl, the objective truth is opcodes, which are well-understood by a small group. Everyone else bases their understanding on heuristics and analogies, and the goal is to write your code to trigger the same heuristics/etc. in the reader.
For the latter, you are declaring your opinion as fact. Every language allows redundancy and variation of expression; if it truly provided no benefit, why have we not seen a popular language that only allowed a single expressive style?
It is indeed my opinion (as prefaced by 'I find myself disagreeing..') but the premise that a programming language benefits from resembling or mimicking features of natural languages is also an opinion.
Also I should note that your phrasing of the question isn't quite correct ("if it truly provided no benefit"), something that provides no benefit is unlikely to be excluded from a language (e.g. double negatives "there ain't nothing here to see!") unless there is a clear benefit to doing so, and in fact there are times that there is.
Particularly I would draw your attention to for example more limited lexicon sets (such as those used by dispatchers, rescue workers, climbers, EMT professionals etc.). Those explicitly exclude variation of expression, since that leads to an increased risk of being misinterpretation in often critical situations. It is my inclination that while interpretation of code isn't time critical, reducing variance (e.g. a common coding style does this as well) reduces cognitive load (makes comprehension more efficient).
What do you think regarding my position on heuristics/forming an idea in the mind of the reader?
Lojban is based on predicate and relational logic, and parses unambiguously for both humans and computers, meaning that we can get straight to semantics instead of faffing about with syntax.
Edit: Lojban is ambiguous with how something is said, so when a speaker says something you should never misinterpret the words, but the meaning could be misinterpreted as I understand it. I'm no expert, but would love to see something like this take off.
I used to have that book... I didn't think it was very good. I wanted to learn more about the various conlangs, but instead the author mostly focused on their creators, and then especially their idiosyncrasies and quirks.
For those who want to know more about conlangs, I would recommend "The Language Construction Kit" by Mark Rosenfelder.
I suspect this is only because there are so few speakers of Lojban. As soon as a language is in common use, it will be extended naturally by the users. I doubt any level of consistency can be enforced over time in that case. Popular slang and idioms generally make it into a language if they persist long enough. Good luck keeping unambiguous parsing in that case.
From the beginning, Lojban's design has included this feature. It would be pointless to learn as a language if you intend to extend it in that way.
There are, of course, ways to experimentally extend the language grammatically, as well as a process for changing the grammar, which has happened before via the BPFK. It evolves, but with planning and consideration.
Humans can deal with ambiguity. There are various reasons for humans to want to be ambiguous, and any natural language has to support that to be useful for day-to-day conversation. Loglan and Lojban might well escape that, if they're only ever used in contexts where ambiguity is not desired and will be repaired if it is found.
Think formal specifications, not love letters.
English = C || English = Pascal || English = SQL .......