That's the whole point of it. Not the caveat really, but the primary feature! Whereas Electron will package chrome in every binary, this uses what you already have installed.
Obviously not great for many product types. You wouldn't want to build a product off of this, knowing that a user might not have Chrome. But for internal enterprise stuff, or community-built tooling - I can imagine this is quite useful, and downloading a 3MB binary is a whole lot better than downloading a 300MB for the same program.
I would love to see this work alongside Electron, where you can provide two download buttons for your app. One if a user has chrome already (3MB) and another if they don't (300MB).
Of course the API and model differences between the two would be hard to solve, and require another level of abstraction.
I would like to see electron as system package. Would work similar to Webview in Android (which is updated as normal package and any app can use it). And the best part is, that it can be done (I mean, create such a component with nice installer and auto updater). Just nobody done it and rather keep bundling full electron with every app.
I started a webview project some time ago, and I see some people using it in their projects - https://github.com/zserge/webview Basically, it provides some high-level APi over a native system webview (WebKit or IE, depending on the OS).
I think it's designed to be a more matinable version of Electron, which bundles Chrome with every app that uses it. I have at least 3 or 4 copies of Chromium sitting around on my desktop at home because I use a few Electron apps.
One time, there was some BeagleBone tutorial that recommended using a Windows version of dd that is implemented as an Electron app. It was 200MB. For dd. Not great. At least this uses the Chrome you already have installed.
Yeah. "Real" native apps feel a lot better, and of course ship you a lot less code.
It is hard to justify the development effort for that, though, so this is the compromise. An app these days ideally supports Windows, Linux, MacOS, Android, iPhone, and the web... and that requires a lot of software engineers. Being able to write the bulk of the code once is appealing. But to the end user... they can tell that shortcuts were taken.