Actually all VW-supplied BB-Codes were not rendering. I have logged into your wiki and triggered a cache rebuild, and they are rendering now.
From what it looks like, the act of disabling VaultWiki before upgrading (as is recommended for the XF 2.3 update) sometimes results in the BB-Codes getting stuck in the disabled state even after the upgrade has completed.
The upgrade is supposed to automatically re-enable BB-Codes disabled prior to the upgrade, if they were disabled by disabling the add-on. However, for some reason, on some installations, those BB-Codes are not being re-enabled.
By the only bug I found, this could happen if the first time you disabled VaultWiki, after upgrading to 4.1.5 or higher, if you already had all VW-supplied BB-Codes disabled, then it remembered that state and kept using it. The bug I found is that the first BB-Code state ever found when disabling the add-on is never replaced by newer BB-Code states at the next time you disable the add-on, causing BB-Codes to always revert back to the state from the first ever disabling after upgrading to 4.1.5.
However, since it was simple enough to trigger the active states to rebuild on your site, then your site was not affected by that bug, and something else is going on.
That bug may also occur, and be possible for your site, if there is no MySQL UNIQUE index on table vw_log for logtype, dateline, loghash. In that case, we would still log new BB-Code states but a random state would be returned each time we try to re-enable them.