This combination is usually invoked on pages that contain BB-Codes and/or allow AJAX posting. If someone uses some VaultWiki-provided BB-Codes (including autolinks) in a post submitted by AJAX, the Javascript here is the "base" needed in order to dynamically load whatever other content is missing for the BB-Codes to render properly as they appear. Even though the wiki is not visible for non-admins, this does not mean that any of the BB-Codes it provided are not visible.
There are some ways we can tweak this, as I believe I have noticed some cases where AJAX edits/replies are not available yet this code is triggered as though they are. In the cases where there are no AJAX posting functions but that have triggers for this code, it may be possible to tweak those as well, as not all result in a scenario where this code is required. For cases where AJAX is available but the likelihood is low that it will result in a VW-BB-Code anyway, perhaps a smaller, custom version of the script that avoids yui_loader.php initially can be formulated.
Regarding yui_loader.php, as this loads various combinations of Javascript (sort of like how XenForo's proxy.php loads various images), I would expect a high number for this in general. We have a few optimizations in mind for reducing its PHP overhead, such as by moving the most common of its combinations to static files, but this would not have a net effect on bandwidth usage.
The optimizations I've spoken of in this post are a large undertaking, and while it's something we're looking at now coincidentally, it will not be ready for the next release, as it requires going through all of VaultWiki with a fine-tooth comb to find, move, adjust various triggers, and possibly refactoring the base script.
As for the FontAwesome, I am surprised that you have an issue with this if you already have FontAwesome defined by something else. My experience has been that a font will not load from the source file if the system already knows what the font is, such by a previous definition earlier in your style. Actually, when I look at the site waterfall, I see that FontAwesome's source file is only loaded once (at the /vault location, rather than the previously defined location). My expectation would be that if VaultWiki were completely disabled, that it would still load once, but from a different location. Since you already use FontAwesome on your site, you can easily remove the VaultWiki definition by modifying the vw_base.css template, thereby loading from your preferred location. For others who prefer to use the external bootstrap CDN, we can add an admin setting for that.