all attention is spent on the code part and making sure it will compile
That is precisely the opposite of the goal of a non-WYSiWYG system like LaTeX or Lilypond. The advantage is (at least supposedly!) that you can just write content without having to worry how it compiles / renders at first. Then in the end when all the content is there, you polish it up for actually obtaining a document.
Does that really play out in practice? Well, it depends. For LaTeX it definitely can work, once you've gathered a bit of experience. Yet many people use it very similar to how one would use a WYSiWYG editor like MS Word, particularly with tools like Overleaf: they mostly look at the rendered output, and only when making a concrete change switch to the code view. This is in some ways counterproductive (in particular when it comes to premature bikeshedding like exact placement of floating figures), however there is a point to be made that particularly for maths formulas, it's just way easier to navigate the neat rendered form and decide what still needs to be done.
With music that's perhaps even more extreme: many composers nowadays rely not only on having a sheet with rendered notes in front of them rather than weird symbols, but also on the various playback functionalities offered by software like MuseScore or Sibelius. If you're approaching it from the perspective that editing a score is performing incremental modifications to a piece of sound, then Lilypond can't work well. But while these sorts of modifications are certainly helpful at some level, I would argue that it is not good to use them as the primary creative tool. It tends to lead to quite superficial music, where every individual snippet sounds good but there is little cohesion, overarching themes etc..
Most composers before the digital age worked very differently: when your medium is just paper and pencil, plus an instrument you can play yourself, you're forced to start out from ideas, motifs, and you also need to plan out the larger structure before actually writing a symphonic score, else it'll take forever moving the parts around. I won't say this sort of constraint is necessary to create great works, but I do think it helps. And that, I'd say, could also be a great advantage of a system like Lilypond: separating the meaning of the different components of a compositions from the actual appeareance/sound of the final result.
So that would mean you should neither compose-by-line or compose-by-beat or whatever, but instead by logical unit.
But again: so goes the theory. Yet, unlike for LaTeX, which is the de-factor standard in scientific publishing at least in some discipline, Lilypond is very much a niche tool (though also not so niche that not many composers aren't aware of it). But they evidently do not find it to be better than e.g. Sibelius in practice. And even I, although I'm very much an advocate of command-line terminals, coding in lightweight text editors, do not consider Lilypond a pleasant tool for creating musical scores, whether newly-composed ones or transscriptions of existing material. Music is actually the only thing I prefer writing on paper rather than any digital form.
Not sure whether it is a fundamental property of music that makes it worse suited for writing-from-code (perhaps the inherent, and desired ambiguity and multitude of possible interpretations), or just that Lilypond hasn't found the best way to go about it.
Of course, a lot of it also has simply to do with what you're acquainted to: Lilypond is complex and you should expect to need at least several months of regular use before you can unlock its full potential. The syntax is in a kind of weird no man's land between Lisp syntax (which was probably natural to the developers, but hardly to most other people) and ad-hoc shorthands to make it concise, but neither is carried out consequently. Leaving aside how good or bad that is in principle, it definitely doesn't help the learning curve.