No, it's not.
It has two major flaws which make it acceptable for video but unacceptable for audio:
1. Nobody envisioned that the Control Point is separate from both the server and the renderer. Yes, I know the design has them separate but for it to really work the CP needs permanent access to both the server and the renderer making it virtually impossible to have a CP on a battery powered remote and also adding lots of communication overhead and latency.
2. The communication overhead and latency part also makes it virtually impossible to do things like gapless playback or multiroom synchronization.
Playlist handling is also a difficult thing. It's defined but rarely really supported.
All vendors that do away with these flaws and still somewhat use DLNA (Sonos and Raumfeld come to mind) work around it by NOT using DLNA as a control protocol but doing their own thing (or their own extensions) and only use DLNA as a means of library access.
Sonos is a good example. You can use Sonos as a DLNA renderer (which does away with Sonos' 65.000 track limit) but it loses most of it's UI capabilities (which are a big strength of Sonos) if you do so.
Nothing of this has to do with the implementation, it's the standard that is broken.
All of this is rarely a problem for video - after all for video you do need a screen which can then also contain the CP - but for audio it makes it the wrong standard.