What kinds of Chrome APIs are you using? Anything related to web styling and DOM should be stable.
What if a bug in Chrome (layout rendering, dom, ..) breaks your application? It's a corner case, possibly it will never happen. But this solution makes impossible for you to roll out a patch by just changing Chrome version bundled.
User will notice a bug in your application and maybe none of his frequently visited web-apps/web-sites exhibits the same bug, so you won't have the user engaged to update (or downgrade!) his Chrome version.
All in all you're breaking one thumb rule which is to use fixed versions of dependencies for your products, so to be sure they always work as intended. As a side note, how is one going to test a GUI build this way? Should it be tested against all Chrome versions that may be possibly installed at least at one customers premises?
The scenario that Chrome is so broken you can't handle it with an update is even less likely, I'd imagine.
We also had a case not long ago where a chrome update introduced a bunch of bugs with stylus input on Chromebooks (a mission critical use case for us)- there we just had to tell people to downgrade to 66 or wait for the 68 update, there was no viable workaround.
Did already have this 5-6 versions ago. We had been unable to fix it without changing a lot of ui. 2 Chrome releases later it was fixed again.
If you accept the risk for any component to break you'll eventually end-up spending your time fixing something other people broke, offering a poor experience to your end customer.
Mind that in corporate environments getting authorized as a software supplier to deploy an update could take weeks if not months, in the meanwhile the customer perspective is that "your product broke" (and made them lose money) - this is why I like to ship as many dependencies as possible in the final bundle.
This is my opinion, maybe biased by the market sector I'm working in. Not saying it should work the same way for everyone, just my 2c.