If GSS advised you to run a specific script, that is within the realm of support since it's coming from us and can be supported. That is completely different than doing something on your own, and I wouldn't recommend assuming you can add projects back in to the database because our KB gives guidance on deleting them to complete an upgrade. If you took a step back and looked at the situation, there just wouldn't be any way we could reasonable support/QE the product with regular customer-driven db changes (this is why our appliance is an appliance and not 'open').
We've historically never supported letting DBAs modify the databases of the appliances, and that is still our official default stance. Reason being, see that KB's Impact/Risk statement: "Irreparable damage can occur if mistakes are made while making changes directly to the vRealize Operations Manager database. VMware strongly recommends taking a backup or a snapshot prior to using the steps noted in the workaround." If GSS tells your DBA to modify the vR Ops DBs on their own, I suggest you make your use case/intentions extremely clear to them and you get acknowledgement from them, then print+frame that e-mail when you get the 'go ahead'.
Another thing to consider. Throughout these upgrades, some of the DBs are changing (from v6.0.x, to 6.1.x, to 6.2.x, all involve db changes in the background). Migrations are happening and data is moving around to get to our planned 'end state' of how we want to architecture to look to allow future feature+capability. This is transparent to the customer, and if you hit the DBs manually to do things, you'll be trying to hit a moving target as you upgrade to 6.2.x. This has risk written all over the place, as these upgrades are considered internal and having customer-written scripts hitting the DBs could lead to unforeseen problems (for the product's stability AND the customer trying to do things).