I've read through most of the document. It looks well-written, technically speaking. I have a few suggestions to offer:
* Begin with the current reality for most people. You mentioned in this thread your frustration with Finale. I had the same frustrations when I was using it at university and I know other people still do. Begin by describing that frustration. Remind people of all the things they dislike about Finale to prepare them for a better way.
* In describing advantages of the plain-text format, I suggest more "customer-focused" advantages (or descriptions of the advantages) and fewer programmer-oriented descriptions. For example, in my current project, a big advantage of Lilypond is the portability of lyrics. I can store my lyrics separately from the music. This means that if I want to reuse a tune for lyrics with the same meter, I don't have to re-invent anything. This is also great when it comes to internationalization. If I have a German translation of English lyrics, all I have to do is drop a reference to the German lyrics.
* I'm not quite sure as to the right way to do this, but I suggest leaving as much of the technical "how-to" discussion as possible until the end of the essay. While yes, there is a stark reality of having to hand code most of the LilyPond file, unless someone is already a programmer of some sort, it seems there is a steep "buy in" curve and throwing code in (no matter how simple) gets an automatic "run away" reaction. If the goal is to persuade someone to use LP, have them so convinced of the advantages (perhaps by doing a point-by-point comparison to Finale) that the code doesn't seem like much of a barrier.