LEDs on boards - pros and cons?
Cons

LEDs can be distracting or outright annoying, especially if used with too high a brightness (modern I_f=20 mA LEDs when actually driven with that current, especially when blue, are blindingly bright wenn one looks too closely at them)
Information overload: if there's too many LEDs, how can you see, without searching the silkscreen or a manual, which means what. Where's the benefit of having an easy to read LED if you don't know which LED to read?

I'd go with something like: as soon as you have more LEDs than you can mentally connect to their meaning after a week of not working on the board, more LEDs have diminishing returns – if you need to consult your design documentation to know which LED means what, a simple test point + multimeter might not be much worse
If the state of your board is complex (i.e. there's many bits – LED on/off – of status), and might be relevant during operation, not just during prototype testing, maybe a board management IC would be wise, i.e. a microcontroller with ADC channels, GPIOs (not only to sense, but also to do things like resetting stuff, or controlling fans, beepers), and a serial port. Maybe even with an OLED display or something. Often, these same microcontrollers fulfill the role of power sequencer, temperature monitor and watchdog.
Sounds like more development work to me, but then again, you sound like you're doing more than one board per year, so maybe putting together a simple firmware once that does what you need is wise, and then throwing the same microcontroller on every board, no matter how simple (personal advise: go for a microcontroller that has USB; your laptop-wielding field engineer (so: most likely you) will like that).
Options range from a few lines of C for your own minimal firmware to using the Embedded Controller Firmware for Chromebooks. I'd not cheap out on the microcontroller too much and avoid going for the 8 bitters – a cheap STM32 ARM would do, for example, and really has the nicer development workflow if you're nowhere near caring for latency in the sub-microseconds.


aside from power constraints e.g. of driving digital logic, overall power usage
potentially: assume you have some reference voltage rail, or other low-current supply rail (say, a low-speed opamp driving a weak load at &lt; 0.1 mA average). You might need to redesign your supply to suit the much higher LED load, or add complex (and thus, new source of failure) means of buffering (e.g. NPNs, digital gates) to drive the LED.

Pros

Looks: A board that has 50 green LEDs turn on, partially sequentially, after powerup is bound to impress your customer
Human Observability: Of course, even if it's confusingly many, having an LED is still worst case as good as having none.
Machine Observability: another LED, simply taped to the LED of interest, on a constant current source, makes an excellent oscilloscope / ADC input
More Observability: OpenCV is relatively easy. Add a QR code to two or three corners of your board, scan for that in a camera picture, use the result to unskew the image, and then use a fixed mask to lazily monitor a board in a lab, while working from home.