There were other features in Unix for "decades", such as Bash Shellshock bug for example.
10M files isn't a huge amount by post-90s standards and talking about disk access destroying hardware is pure hyperbole. If you have disks failing that frequently something is wrong with your server room, cooling, etc. A daily cron task is not a make or break problem there: I mean, 15 years ago I had that many small files backing a departmental email setup (maildir, so one file per message) — if you think locate is a problem, consider the I/O characteristics of hundreds of IMAP sessions and remember that RAM was a lot more expensive back then and many individual users had mailboxes larger than the aggregate total server memory). Drives failed, yes, but usually after years of heavy service.
> In the server distribution patch instructions, it often says "reboot your computer", whereas one can just restart the services like in the latest openssl security update.
It seems like a bad idea to criticize them for taking the safest tack in generic documentation intended for a wide audience. Some Ubuntu servers are run by veteran sysadmins but others run by people who are learning, primarily working on other things, etc.
Restarting processes requires a decision per-patch to understand all of the affected components and safe restart strategies for all of them – e.g. in the case of OpenSSL, the library will be loaded not only by services but also other long-running jobs – cron tasks, anything a user has been running, etc. Yes, you can script looking for open file-handles and try to restart everything but if that goes wrong in any way, you're running with a known security hole which people will incorrectly think has been patched and may even claim that a scanner must be reporting a false-positive (I've personally seen that).
If I was writing documentation to give to non-experts for operations, I'd make the same choice every time because it's simple and fails safely. Experts probably aren't going to read that documentation anyway and have enough knowledge to understand when they can make optimizations based on local knowledge.