Actually, what you've described confuses ballooning and 'same-page-merging'. I'll try to elaborate on the two to make the distinction apparent.
This is a trick to make sure that some of the memory allocated to the guest virtual machine remains usable by another guest or the host itself (caches, etc). It's done in the following way:
The guest kernel is injected with a driver, that monitors guest memory usage, and 'steals' some of the unused memory (allocating it for itself in the guest memory space, thus making sure nothing on this guest can touch that range).
Then it informs the host kernel, that it can in fact remove these memory pages from the core, that they are not going to be used in the guest (until the guest experiences some memory pressure, at which point the balloon will deflate, and use these ranges again).
Ultimately, the kernel can allocate the exact same memory to another guest, and make the entire memory usage a lot more efficient if the guests are running with a lot of free memory.
Same Page Merging
This technique identifies identical memory pages, that for some reason are not already marked 'quasi-read-only' with copy-on-write, and marks them as such.
Now, on the OS level, there is limited need for these kinds of tricks. Simply enough, most time when you have identical memory pages, they are already read-only (sometimes even without CoW), since these are mostly applications code, libraries etc. They are natively opened through a Memory Map, and thus the kernel can keep only one copy of them in core (if any at all, it can also completely page it out, and allow it to be paged in from primary store as needed).
On the virtualized OS level, the same principle is properly applied within each guest subsystem. However, the host kernel, has no idea if two of the guests are running mostly the same code, and thus are sharing the same memory - the guests don't communicate to coordinate that.
Which is why it can occasionally scan the entire system for identical memory pages - most of the time, they will be identical across the guest OS's, not within each one - the guest kernel makes a decent job keeping the memory neat within it's range. Thus, in the typical VM environment, where one host kernel handles 50+ guests, the memory savings can be pretty substantial.
Both at once
Ballooning and Same-Page-Merging can co-exist very well, achieving pretty substantial memory overcommit for identical systems.
To answer your question - the Same-Page-Merging can and sometimes is enabled at an OS level. It has to do with page sharing that are interpreted, and thus could end up being identical without having the same backing file.
In your Chromium example - the process binaries themselves are already deduplicated through read-only startup map - they share the exact same memory space. The page caches (contents of the tabs) are usually also shared between processes (read-only copy-on-write) due to the way disk cache is managed - the same on-disk file can be opened simulatenously between different processes in the VM-optimal sense.
This is different on mobile systems. Android, for instance, extensively employs KSM to deduplicate identical code between different applications.
In either case, you can enable it yourself on Linux (Kernel SamePage Merging). The driver exports various statistics that, after reading this answer, you should be able to interpret, and make your own decision whether it's a good match for your purpose.