So long as the foundation and the official “owners” of the kernel are US based, then the real answer is “because it’s the law”. Despite the fact the kernel is maintained and used throughout the globe, other countries’ laws are entirely irrelevant, but people who employed in a country are typically held to its laws.
The real mistake was having a registered company in the US that they’re unable to realistically move abroad.
In a world with sense, someone vaguely accountable in a new country will fork the kernel, that just becomes the de facto new kernel, doesn’t seem likely. We can only wait and see.
If there’s a serious security bug, like Heartbleed, you should totally update and reboot the service. That is basically the only “must” for staying atop things. The rest is mostly personal preference.
In my job I maintain publically exposed Linux servers, and many of them don’t get rebooted for years. I think our record is about five years.
Yes, if you want your server to be theoretically the rootinest tootinest securest setup ever, you should update about every 6 hours, but even then you’re just more vulnerable to repo attacks (which have happened a few times lately). Apt upgrade every month or three is probably good practice to keep on top of bugs.
So really, how frequently do you need to reboot? Eh. So long as it works, there are no critical kernel vulnerabilities, and updates are available, I really would argue you should never “have” to.
Servers are horses for courses, if you’re being heavily targeted by hackers, obviously stay on top of updates, but if your server is pootling along without harassment and doesn’t contain life-altering stuff if it got leaked, then don’t worry too much. A standard, barely-changing, ‘stable’ build is usually a very secure one.