The trouble is that it is often not obvious what is being broken. For example, I find that it is common for it to suggest a downgrade, sometimes quite significant. This often will break things but it won't be obvious. In other cases, it commonly recommends new major version uplifts and again, these can seriously break things.
Only if you understand what it is doing. The problem is, even as an "expert", it is very often not clear what impact changes will have or how they might manifest. For anyone not an expert in node.js and npm, it is an impossible task which is why, in this forum, I always recommend NOT doing it unless you really understand the impacts and consequences. In general, except for people in tightly-controlled, secure environments, the impacts of the various security issues are minor anyway and it is all too easy to go too far. (And this coming from someone who is certifiably paranoid!)
Production containers for something as fast-changing as a node.js environment can be may require significant support and development effort. OK, if you have the commercial setup to manage it. For anyone using Node-RED in a personal environment, the overheads simply aren't worth it.
Also, having a complete Node-RED setup, including nodes, in a container means that the node list is fairly set in stone. This can be a good thing for commercial environments of course, but again, a pain where more flexibility is required.
Commercial, production use of Node.js apps is a very different proposition to other uses. When asking for help in the forum, it is best to make clear what type of environment you are working with.
If I were working in an environment like yours and needed to service many customers, I would certainly have a Continuous Deployment service set up along side dev/test/live environments. With probably several test environments up to pre-production, client-facing test environments where at least some trusted clients could test changes before live deployment.
That service would also include a range of continuous security tests. I would likely also have periodic cyber penetration tests. All somewhat dependent on the value and cost of course.
Personally, I would be extremely cautious about deploying something like node-red into a sensitive environment (health, critical infrastructure, etc). It adds an awful lot of attack surface area that may not be especially well understood in detail.
But I'm drifting off-topic of course. 
Back to the original topic, I stand by my original assessment in general, don't do npm audits unless you know what you are doing, have a specific security requirement, and have the resources to deeply check the impacts.
By the way, UIBUILDER also uses npm for managing front-end libraries. However, it makes the assumption that you won't be likely to be using Node-RED in any scenario where you would also want to install front-end libraries without already having npm installed. So it uses your already installed version, not a separate instance. In fact, it uses a command shell since, from the earliest days, npm always said that their API was subject to unannounced changes. I think that has changed somewhat now and maybe UIBUILDER will also change in the future, but so far, nobody has complained.
