This is actually getting better, as most of the transit providers already rely on software companies that provide their own route planning software for passengers and/or administrative software like tools to create the actual schedule with. These companies are slowly getting better in providing standardized feeds.
I am skeptical that something like a feed-wiki would work, both because of vandalism, and because schedules are usually incredibly complex. You may have noticed that your bus starting at 14:30 from station X was scheduled incorrectly, but does this service has this mistake every day? What about the 3 days a year where this bus has a slightly different schedule? If the bus travels every 5 minutes, and each trip has this mistake, you have to manually check hundreds of trips per day if they contain this mistake. Automation is difficult here, because trips that occur frequently are very often not grouped by any mechanism (although for example GTFS provides such mechanisms).
I think the better way is a legislative change which requires all transit companies to submit their schedule data to a central authority, which then publishes the merged schedule.
There is now (since the beginning of 2020) a new EU regulation [0] which basically pushes for an EU-wide multimodal route planner and schedule dataset (published in a special format, NeTEx). This makes it now possible to rely on the data of existing national schedule aggregators, which have been checking and merging timetables of all national transit providers for decades. For example, in Switzerland, the national railway company SBB does this (GTFS feed published here [1]), in Austria its also the national railway company ÖBB, and in Germany, its Deutsche Bahn (GTFS feed published here [2]).
[0] https://eur-lex.europa.eu/eli/reg_del/2017/1926/oj
[2] https://gtfs.de
This doesn't seem to apply to mid size networks and smaller.
For example, when tree falls and blocks a road, in a midsize network there'll probably be one admin-person in the office who decides what to do about it. Usually they'll just print off a paper sign saying "All services to X won't go past Y today", then ask a driver of another service to put that sign at each stop. They'll log into the website and put a banner at the top saying the same, and they'll ring the local radio station to announce it.
At no point does that info ever go into a computer in a machine-parsable form. Even if it did, timetables are probably saved in a big MS Word document.
It is a lot easier to convince a small bus operator in a rural area to just enter cancellations / delays into a website than it is to convince him to buy and administer servers and software to built its own real-time service.
There's also the Tripshot model -- an enterprise product where drivers install an app on a cell phone to track ridership, and it also sends the gps coordinates along.
That said, the other arcane part of transit directions is that if you update or break your feed, you have to wait hours or days before the result shows up on Google. (Sigh, batch processing...)
They only scrape daily by default because some transit providers host their multi-gigabyte GTFS feeds for all bus arrivals for the next century on an ISDN line...
Anecdotally, at a local system I once used there was an issue where drivers were intentionally not turning on the locating tracking, or configuring it incorrectly, because of this.
Creating a transit data feed typically requires local knowledge, technical knowledge of data feed formats, and access to make changes to the data feed.
Actual transit providers typically lack the technical knowledge, especially for making day-to-day service updates. Transit enthusiasts lack the access to make changes to the feed. Google and mapping companies lack the local knowledge.
End result: Probably half the worlds population's local bus/train isn't accurate/present on Google/Apple/OSM maps.
How can this be solved? Perhaps some kind of feed-wiki so the three interested parties can do human collaboration?