First and foremost, I think that what Google wants is irrelevant. If it wants to fix the endemic fragmentation and the software update problem, a greater level of control (going proprietary) is required. If it doesent go there problem not fixed. Desire does not come into this, its a necessity.

Furthermore, for a company that doesent like proprietary code it certainly seems to have a lot of it including:
1) GMS the scope of which has been getting bigger and bigger over the last few releases rather than smaller. An Android phone today is far more proprietary now than it was 5 years ago.
2) Android Wear
3) Android Auto (for headunit)

VTS adds another control point on top of CTS for GMS. Anyone who creates GMS for Android will tell you that the CTS is used by Google to ensure that its services and not those of competitors are front and centre of the device. This is how Google generates revenues, the good of the open source community does not come into it. That bit is just marketing garnish albeit a very successful one that keeps developers happy.

“In addition to the architectural changes, we’re working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android.”

That is, for things that would have potentially broken in the VTS, they ask the vendor to contribute it to AOSP so it can be updated as a part of the Treble frameworks updates – that is, everyone gets the vendor contributed work. Treble pushes everyone to be less proprietary, not more.

Other errata: The word you’re looking for was “Nexus” and not “Nexis”.

There are a few things you don’t seem to understand about how device updates work, and why there’s been such a roadblock to get updated devices into consumers’ hands. It isn’t falling apart for lack of motivation on the handset manufacturer’s part – even when Lenovo wanted to keep the Moto E updated, and promised that they would, they ended up breaking their promise and not shipping updates to US consumers. They did manage to ship updates for the same device to non-US worldwide consumers. How does this happen?

When you’re a handset manufacturer, you not only have to take BSP and recompile it for your handset, you have to get it through several approvals. Here’s the steps: CTS, which you know, is about delivering what was originally called the “with Google Experience” but we know as Play today. It doesn’t end there.

If you ship a phone in the US market, you have to get it qualified initially at the FCC, and then separately at a lab that partners with the carrier you wish to sell the phone through. This has a testing cost, and it’s not inexpensive. When you want to ship an update to the phone over the air, because it’s changing in a material way, it has to be re-qualified. The carriers are deathly afraid of putting a handset on their network that will harm their network in some way. Apple gets around this by releasing the betas to developers at the same time. You get to do this re-qualification testing for each handset you wish to update, and each carrier you wish to sell through. It snowballs dramatically.

If you’re a Samsung or Motorola, you have to keep a stockpile of old phones in order to develop, test and requalify for the network. It’s a huge imposition. It’s not that the process is arduous to test updates – that’s relatively simple compared to the cost of maintaining old phones and paying to test them for each update x5 major US carriers. And that is how worldwide versions of a Lenovo Moto E got updates and the US version did not. Most phone manufacturers simplify this and simply decide if they aren’t going to do it for the US market, they won’t do it worldwide.

“Project Treble aims to fix this by adding in an abstraction layer between the Android OS and the vendor modifications such that the underlying Android OS can be updated without the manufacturer losing compatibility.”

Not the purpose of Treble, but a good side-effect.
What Treble does is change this landscape. Because the vendor specific bits don’t change, they won’t require requalification for the carriers. By splitting it out, the Android frameworks can update leaving the vendor implementations the same. That doesn’t make Android proprietary, and again, that’s no one’s goal. Treble makes it unnecessary.

The modifications for HTC’s edge sensors are a lot like the modifications for Samsung’s bixby – they run in an app, and are updatable, just as Samsung took away the ability to change the settings for the button that launched Bixby recently. These sorts of additions should not break the VTS as you suggest. They’re essentially apps that talk to the OS, not changes to the OS. You can modify beyond the paint on the interface (remember, interface is how you interact with it, not just how it looks) provided you aren’t altering OS frameworks that are going to be replaced with updated versions. As it is, you’re suggesting that Samsung Iris scanner equipped devices won’t be possible for Android O (developer preview already is using Project Treble).
I don’t believe that will be the case.

VTS doesn’t limit the differentiation, it just pushes it as a separate blob of software from Android OS updates, and if the handset provider wishes to update their implementation, that’s going to have to undergo all the carrier testing.

“An easier to use and more consistent platform would most likely increase traffic generation and therefore Google’s revenues which on Android remain half of that generated on iOS.” – This is more a problem with Material Design and less a problem of OS skinning that you’re talking about. A better question is, what is it about Material Design that causes as much as half the use for some use cases? What are the engagement actions people do on iOS that they don’t do specifically on Android, and what are the root causes for that? I suspect it isn’t OS Skinning that’s the root of the problem, but instead, Material Design assumptions and app interfaces that are the problem.