It does not matter what you use or do not use. As long as it is offered, then some internal detection mechanism has determined that it is needed. I am generally not getting concerned with this level of detail, but rather with the end result. For my purpose, Windows Update/WSUS are authoritative.
The Office build number depends on few factors.
If you look at the current Microsoft documentation for Office update, all patches for a month are presented together as CU.
https://blogs.technet.microsoft.com/messaging_with_communications/2017/07/03/current-cumulative-updates-for-office-q3-2017/
https://support.office.com/en-us/article/Office-Updates-a118ec61-f007-492f-bfa5-5a6f764d5471
They act as a group. I don’t know what happens when only some of the patches are applied, while others are not. Would the build number for Word be different than for Excel for example?
When Visio and/or Project are installed in addition to the main Office suite, patches for what seems to apply to one product, apply at the same time to other products, while sometimes there are duplicates in the list.
Office Update is based on Microsoft Installer which I think is very much like the XP style of updating and totally different than what is known as CBS starting with Vista. CBS is the current model of updating Windows and in a larger sense how Windows is constructed from modules.
If @abbodi86 read this, I think he would be able to provide more insight at the level of detail which does not concern me so much.

Old article, still current as contents about correct Office patching
https://blogs.technet.microsoft.com/messaging_with_communications/2011/08/04/keeping-up-with-office-updates/

All Office updates are cumulatives for the product/component they patch, which is determined by the file name
meaning as example, latest word2013-kb3213567 update replaces all previous Word 2013 updates

traditional MSI Office installation overall version does not get updated or changed with individual patches, only a Service Pack change it
however, the individual patches changes the build version for the components/files they update
example, latest word2013-kb3213567 update is 15.0.4945.1000, whereas Office 2013 SP1 version still 15.0.4569.1506

of course you would need all latest individual updates for the products you have to get current
https://support.office.com/en-us/article/Update-history-for-Office-2013-19214f38-85b7-4734-b2f8-a6a598bb0117

@abbodi86
If I check the catalog or WSUS for supersedence, it is not handled exactly as you mentioned here. It is largely consistent every 1-2 months but not entirely.
Does this mean that either the supersedence is not correctly updated in metadata for each patch or those updates to which I made reference refer mostly to Office as a whole and not to separate products?
I am normally not concerned with individual patches, but I would like to reduce the numbers of those installed at any time on the machine by having only the latest required and not keeping the old one which bloat the machine.
You posted in the past ways of removing old office patches which are convoluted and not supported in general and I will post another one here, easy to use which is HomeDev’s PatchCleaner, not supported officially and risky
http://www.homedev.com.au/free/patchcleaner

Yes i know, metadata supersedence doesn’t always reflect the true supersedence chain
specially for Office updates, were Security Update is never marked as superseded by a General Update (there could be a special exceptions)

but the Windows Installer / Windows Update is smart enough to calculate supersedence based on product patches version

thanks for that
yeah, all methods seems to be risky and needs a closer look to be sure

Wow !  I have hundreds of entries in HKEY_CLASSES_ROOT\Installer\Assemblies

All seem to be referring to items like

c:|Program Files (x86)|Microsoft Silverlight|3.0.40624.0|de|Microsoft.VisualBasic.resources.dll

c:|Program Files (x86)|Microsoft Silverlight|3.0.40624.0|de|mscorlib.resources.dll

c:|Program Files (x86)|Microsoft Silverlight|3.0.40624.0|de|system.resources.dll

Is it safe to delete the lot of them?