My sense (after writing parsers for ABC, MusicXML, Cappella, Noteworthy, and about 6 other formats; and output to Lilypond, etc.) is the limitations of ABC, the format, cannot be completely separated from the limitations of ABC parsers. As both Kevin and Chris noted above, the ABC format has the capacity to encode much of the complexity of MusicXML and Lilypond and other formats, so it is not especially limited with respect to those formats (though the precise formatting and layout options of MusicXML and Lilypond, necessary for storage of a score that can be reconstructed, are rudimentary).
The limitations arise in that an ABC parser cannot know from the data format what types of ABC extensions or seldom-used features it may encounter at any moment or how the language may evolve in the future. As far as I am aware, there is no formal grammar for a well-formed ABC document that would let a programmer know where the following chain of elements (lyrics, voices, etc.) would end. Contrast with MusicXML where the XML format of <tag>contents</tag> has a sort of encapsulation that is easy to parse and can be tolerant towards future changes in the specification. (Lilypond is harder to parse or generate in this way, but it does have a grammar specification that can help). The difference means that MusicXML readers (or the few Lilypond readers) can know whether a file is well-formed in advance, and selectively parse or read elements that may or may not be relevant to the task. With ABC notation, it can be extremely difficult to skip information that may be correct but from a different (older or future) standard.
Because it evolved from a (great) way of simply editing music, some aspects of the implied grammar are contradictory or and can lead to very different output depending on which parser or interpreter is used. For instance, the 2.1.1 (dev) spec says, "A percent symbol (%) will cause the remainder of any input line to be ignored." however, later "A stylesheet directive is a line that starts with %%, followed by a directive that gives instructions to typesetting or player programs." (as in the %%score directive above). Such non-standard additions let the format grow according to the needs of the community, but make parsing of important features difficult and leave a somewhat non-standard standard. Important constants or attributes, especially in these directive signs, are left undefined: one can see that there is a "%%papersize" directive, which can be followed by "A4", but is the US version of this directive "letter" or "8.5x11" or "8.5" or "8.5/11"? In Lilypond or MusicXML such constants are well-defined.
If the OP wants more specific limitations rather than philosophical, some important ones: little or support for tuplets beyond basic information (how they should be displayed (number, ratio, no sign), nested tuplets, placement in metronome/metric modulation marks); many fewer ornament (decoration) signs; support for early music signs (full in Lilypond; a few in MusicXML) and contemporary notation symbols (diamond harmonics; cluster chords; microtones etc.; full in Lilypond; some in MusicXML); control over positioning of grace notes, in particular grace note groups in multiple parts (useful for a Beethoven symphony); different key signatures in different parts (very important for Beethoven symphonies; needed even after the transposition settings are complete since trumpets should not have marked key signatures in any transposition). Richer metadata (arranger, copyright [for the piece, separate from the encoding]), precise control over bar numbering schemes. Rich instrument playback support (in MusicXML 3.0; as opposed to pure MIDI number).
None of that is to say that ABC is a limited format -- it's incredible for making simple things simple and writing music by hand in a text file, but for something as large as a Beethoven symphony, I believe that the limitations will make it a vexing choice.
(edited:) You asked if there was a non-subjective way to decide how important these features are; I tried to answer in the context of notating Beethoven symphonies, since you used that example, but let me answer in the context of how people might use notation here, maybe a bit less subjective. For questions about "What does X obscure symbol mean?" It'll be much more possible to make that symbol in Lilypond or MusicXML (assuming it's a baroque trill sign, a contemporary notation sign, etc.); of course the questioner probably couldn't use it in his question, since he'd have to know the name for it, but an answerer could use it in her response. Guitar chords are often discussed here; they can be written in ABC, but except for this list they have no semantic meaning (treated like text expressions); they are fully supported in both other formats (along with figured bass for baroque music questions). For theory questions ("What's an augmented 6th chord") ABC would work fine and be much easier to enter.
