There is another, arguably legitimate differentiating feature:

How up to date the embedded web engine is (and how quickly you would be able to merge upstream changes, update the framework, wait for "browsers" implemented using the embedded framework to update their dependencies, etc.) That can be a pretty big deal when there's a fix for a high-impact vulnerability.

There's another security consideration here: whether you trust the webview not to peek at your https content.

With a known browser, you get reasonable guarantees that TLS is being handled properly. With an unknown browser, these guarantees are gone. Considering the average person has no idea what https/TLS is, banning all unknown browsers as a defense against phishing seems completely reasonable.

HTTPS isn't even the largest concern - it's the browser being some malicious app asking to 'sign in to Google to load your profile' and stealing either the password or auth token.

What's frustrating (and clearly anti-competitive) is that Google thinks this is a problem enough to justify this, but refuses to ban browser extensions that utilize permissions broad enough to allow them to do this in Chrome directly. Browser extensions can generally collect everything on web sites and that you enter into websites, and has access after all TLS decryption has occurred.

For the most part, if a browser's extension store isn't in order, everything else they claim to do to secure web traffic is kinda a joke.