The problem is that with the way multi-process browsing works there is a long-lived parent process, which is only shut down when you fully close the browser, and there are a number of potentially shorter-lived child process that handle the actual browsing and rendering of web content.
So at any point the browser needs to be able to potentially launch a new child process if you open a new tab, or even just browse to a different website on a different domain (origin) – which thanks to site isolation nowadays requires a separate process, too, unless perhaps a page from the same origin is already open in a different tab.
If thanks to an ignorant update service the browser's binaries have been swapped out from underneath it, that now means that you've got an "old" parent process suddenly talking to a "new" child process, which isn't an officially supported configuration.
If you're lucky, there were no breaking changes within the browser and things might work anyway, but there are no guarantees that things always turn out that way, since the API between parent and child processes is a purely internal one and browser developers feel free to rejigger it any time they need to.
While in principle you could try to develop the browser in such a way that a certain amount of forwards/backwards compatibility is preserved between an older parent process talking to an updated child process, I presume that doing so would also significantly complicate development on anything that touches the parent/child process interface, and you could equally claim that it's Linux's package manager behaviour regarding updates (just swap out the files underneath a running process) that's broken.