A decentralized grid system is the best of all possible designs for public transit, but it depends very heavily on having very high frequencies- say, 10-15 minutes at the outside, preferably closer to 5 minutes- on every route in the system. If you can't pull that off, it's better to design your system as a hub-and-spoke system, like RTA's, and to engineer timed transfer (or "pulse") points at each hub. (RTA does this, but they don't advertise it well.) That way, even though frequencies as a whole are abysmal, transfer wait times at system hubs are significantly less than they would be if buses just randomly met along their way.
The trouble with moving from a hub-and-spoke system to a more grid-like system in a relatively low-ridership system is that these timed transfer points become almost impossible to engineer. On the Tallahassee map (PDF), line M is a not-quite-downtown north-south route that crosses nearly all of the east-west routes at different points. It would be nearly impossible to schedule the M so that it connects well with the E at the end of its run, the A and C outside of downtown, the F, the T, the D, the L and B, and the G all at different points. When you then consider that each of those routes would need to be scheduled based on a similar number of transfer points, you might get a very fragile and illegible schedule that is operationally very difficult to maintain (eg. one bus is late, breaking the whole system), or (more likely) you get very little concern for the wait time of people transferring, so that the average wait time for the next bus is awful. (Average wait is 1/2 * frequency, which ranges from 20-50 minutes in Tallahassee, and from 20 to 120 minutes on RTA.) In a well-designed "pulse" system, transfer wait times can be reduced to mere minutes at the hubs.
We actually have a local example of a low-frequency grid system: OCTA. Back in the 80's, OCTA went from a hub-and-spoke system to a grid system, with decent frequencies and promises for improvement. However, the grid-supporting frequencies never materialized, and riders are now stuck with interminable transfer waits at unpleasant arterial intersections.
Part of the reason I think I keep seeing this idea reoccur is that grid systems work well for nearly every other sort of network. It goes without saying that cars love grids, but just last month I was also extolling their virtues for cyclists. This is an example of what Jarret Walker talks about in the recently-posted introduction to his book:
For example, in most debates about proposed rapid transit lines, the speed of the proposed service gets more political attention than how frequently it runs, even though frequency, which determines waiting time, often matters more than vehicle speed in determining the total time a transit trip will require. Your commuter train system will advertise that it can whisk you into the city in thirty-nine minutes, but if the train comes only once every two hours and you’ve just missed one, your travel time will be two hours and thirty-nine minutes, so it may be faster to drive or even walk.
I can explain the concept of frequency to a motorist, and she may even understand, intellectually, why it’s important. But what she knows is the experience of driving, where speed matters and frequency doesn’t. So when she makes a decision about a transit project, she is likely to give frequency too little weight. The result can be services that are very fast but don’t come when we need them, or that require too much time to connect from one service to another.Similarly, hub-and-spoke designs for transit pretty much only make sense for transit, because transit travel time is linked inextricably to service frequency. When you draw lines on a map, it looks terribly inefficient- but you have to realize that, at least outside of big-city transit networks, lines on a map are a very small part of the reality of transit service on the ground.