Hi Adam, nice to see the proposal formalized 
I think it makes total sense to introduce some form of budgeting to our treasury spending, no government or enterprise would last long without any control over how their finite resources are used. Limiting the bandwidth of our spends as your proposal suggests is crucial and needs to happen, but something I would consider adding already that is more important when budgeting is to accompany the spending with goals/purpose/direction/vision, with some mechanism to allocate resources where they are needed the most. Imagine you are planning a trip to Europe and decide to limit it to 5K, the limit would be pointless if you use most of your budget going in first class and don’t leave anything to even afford the cheapest hostels or go to any restaurant.
One way I would suggest we can adjust the proposal that would enable this goals based spending is by defining treasury spend tracks not based on amounts but on the category of the spend(e.g. media, events, marketing, wallets, core tech, r&d, etc.), the limits on each track should add up to match the bandwidth you proposed, we can start with a balanced division or discuss a bit more to have a general sense of what topics could have more priority based on our short term needs(e.g. do we focus on positive revenue?), it doesn’t have to be perfect but just a starting point that would be adjusted over time.
As side note, I know bounties serve a similar purpose but it’s just my personal opinion that OpenGov and its delegation system should deprecate them or we should evolve them to overcome the centralization around curators(e.g. with curated payments). Another advantage of separating tracks by domain is that delegation per track starts to actually make sense as domain experts can finally campaign for specific tracks making the most use of their expertise, a marketing expert can ask for delegations to the marketing related track(s) instead of pretending to understand a complex big spender proposal about a core technology.
If people like the idea, a couple of minor non very functional additions I would introduce with this change that builds on this notion of having goals and clear objectives similar to how companies define OKRs is to first include a scheduled remark, say in 2500000 blocks(~6months), that states our main goal for the semester and also acts as reminder to review our governance parameters and adjust them(with a new objective remark). The second change would be to add a new goal property to the TrackInfo struct that shortly describes the track but most importantly states the track’s current focus or priority, e.g. a BigEventSpender with goal: "Only sunny places with canaries", suggests voters to reject igloo parties organized by penguins 
If any of this make sense I’d be happy to formalize the changes and help in any way necessary to bring this referendum on-chain, perhaps with the help of other non-parity/non-big-funded-team fellowship members whom also live off OpenGov and the treasury(@sam?). I simply think a long due milestone we need to overcome in the spirit of decentralization is for the community to propose its first runtime upgrade independent of Parity’s usual workflow. This proposal with low technical complexity and with very little risk to brick the chain can be the perfect test case.
P.S. Out of curiosity, would the linear regression look the same if counting not from block 16,000,000 but around 15,500,000 which is about the time OpenGov was introduced?