I'd also find it very helpful to have BV pull the values from vCenter as this is where most peoples workflows are taking place. If there's room to also use BV to manage values and to do two-way sync (or configurable one-way sync from BV), even better. The main point is to have vCenter as the canonical source of information in case of doubt.

This way, vSphere setups could quickly be amended by Veeam-powered mangement charts, while leaving admins the flexibility to make changes as they are used to. This is not only a matter of taste, but also because of (automated) VM deployment processes which usually take care of filling in the values. If BV ignores those, its data source becomes outdated and its reports obsolete.

From a technical point of view: doesn't BV even pull and update values from vCenter intially, only stopping to do so once a first change is made in BV? At least that's the impression a quick test just left me with.

You can always launch a "mapping" wizard to import custom attributes from vCenter Server, see User Guide (pages 22, 34-35).

Keeping vCenter Server as a canonical source will make a custom attributes management really complicated, there is always a great chance of human error/typo while setting custom attributes manually through vCenter Server. That was one of the reasons for creating auto categorization rules and dynamic groups.