The example you're giving is for an application that operates on files. In that case, naming the menu "Files" obviously makes sense.
But the obvious example of what op is talking about is Pidgin, an instant messenger. The first menu is called "Conversations". It has actions for operating on conversations. The application can't open files, or save files. At least not in the same sense as Notepad, Paint, Audacity, etc.
The calendar example is from the article, their suggestion is "Event"! But also, yeah that's a weak choice for me to pull from.
I guess my point is "File" is just consistent, not that it accurately represents the way the application functions. A lot of UX conversations come down to the naive-user experience, but truth be told, you're only a naive user for a short amount of time. Maybe a week into using macOS for example, I think you'll just mentally map "File" to that list of actions I have in my comment, and you're golden.
Yeah maybe conceptually it's weird that "New Tab" in safari is a File action... but also that's where every application puts its "New Thing" actions. If I want the application to give me a blank slate, I will look for File > New *. "File" is just a word.
If every application had it's own place for those actions that were named for the noun they act on, sure, the naive user touching a desktop OS for the first time is going to breeze through tasks a tiny bit faster, at the expense of the location/name/grouping of menu items now requiring relearning on an app-by-app basis.
There's an alternate history where the file menu is actually labled "Do" or something, and I would make the same argument. "I know what's in the Do menu."