Canonical (employees of company behind Ubuntu 'main' repo.) & Ubuntu members/people/community have tested everything in the repos for the specific release of Ubuntu they are available for.
If you download a .deb from elsewhere, any validation & testing performed on it may be of a lesser standard than that required for inclusion in Ubuntu repositories. One quick difference may be just the validation of what packaging rules it follows (eg. they may use debian standards; fine for debian, but may create problems with ubuntu or another distribution) , the ABI/API's it expects were tested/untested by whomever developed/packaged it & may work with specific libs (Qt or GTK+ releases) so again it's what @SergiyKolodyazhnyy covered in the 'trust' statement in ensuring it matches your system. A wrongly packaged install may create problems that show in other correctly packaged software - ie. you must ensure it's suitable.
An quick example using packaging rules - apt & deb packaging tools (dpkg etc) will upgrade by version; so a poorly packaged version may use a different standard. eg. a coder grabs ver 2.2.2 code, makes a few changes and marks it 2.3 so it'll replace the 2.2.2 files. The next release comes out marked 2.2.3 but it won't replace anyone's 2.3 release as 2.3 < 2.2.2. This is a [dumb] simple example of issues just in packaging as groups follow standards that makes sense to them, having lots to choose from and not all 'play' well with others. More serious issues though are API/ABI changes which are hidden inside packages (and not my simple naming/versioning example)
Larger companies with tech savvy people tend to be a little more aware (ie. do some homework), however their bosses commonly still watch the clocks (ie. $s) so don't want to package a debian version, a ubuntu version, mint version etc. so create one that they believe won't create issues for any. With open source packages, you can sudo apt source to view & review the source code yourself if you don't trust the review process used by Canonical or Ubuntu repository software. For PPA's or 3rd party sources this review isn't required, but at least source code is still available meaning you can do it yourself (please note: some PPA's do have reviewed code). You have even less chance of review if only binaries (.deb) are provided; involving more trust.
For stand alone programs like a browser (your question on chrome), it's interaction with the system is minimal & mostly simple eg. save downloaded files, so the chance of causing issues elsewhere may be somewhat reduced in contrast to a possibly a gnome-extension (that if crashes, causes the user to be logged out when gnome-shell crashes), but each non-official package needs it's own assessment on 'risks' (what release of GTK+ or Qt toolkits does it expect; are you running etc).
If you use the Ubuntu repositories - all this 'homework' has been done for you to ensure the system remains as stable as possible, and matches other repository tested packages.
apt& deb packaging tools will upgrade by that version; so a poorly packaged version may be ver 2.2.2 (with a few changes) so was marked 2.3; but later fixes come out marked as 2.2.3 which include what the coder added to the '2.3 package but without additional fixes in the correctly 2.2.3 package - but systems with 2.3 installed won't upgrade/install the 2.2.3 correct package as it's version is less than 2.3. This is a simple example of issues just in packaging as groups follow standards that makes sense to them, and there are many 'standards'. – guiverc Apr 26 '19 at 23:43sudo apt sourceto view & review the source code used, if you don't trust the review process used by Canonical or Ubuntu repository software; for PPA's or 3rd party sources this maybe a a step not even done; likewise potentially for google (what do they say?) – guiverc Apr 26 '19 at 23:47