The price you pay is that an LP score is considerably more time-consuming to enter
I feel there are at least two factors that create this situation: the lack of graphical interface limits the amount of selection tools (you can basically select what your cursor can select). With more selection tools that allowed the user to easily copy, paste, cut, insert, attach articulations to all staves, etc., entering notes in Lilypond would be way faster. Since I started using Python to help me create Lilypond files, I can have whatever amount of lists I want (for example one called "tutti") and use programmatic commands to affect all staves. F. ex.
for staff in tutti:
add_music(staff, "c4. d8 e4 f |")
Where "tutti" is a list, e.g. tutti = [flute, violin, cello] and add_music is a function I programmed to add more music to the end of the staff (amongst other I programmed, like copy_bar, insert_bar, etc.).
The other aspect that makes working with Lilypond unnecessarily slow is the fact that invoking the Lilypond command always processes the whole score over and over again from scratch. Telling the user that their scores are gonna take more time to compile every time they enter more music doesn't sound attractive nor efficient. The alternative, only working on the text file from beginning to end with no visual feedback to then proceed to "debug" such file after compiling is not a realistic alternative for the majority of users. In my Python script I'm using subprocesses in conjunction with OLL's partial compilation that let me make pdfs page by page (using pdftk), so that I can only update the page I'm working on without losing the rest of the pages.