I've been operating auto-curation bots on Steemit since October 2016, and in the days leading up to HF19, things were looking good. After HF19 hit, payouts appeared to go through the roof for a short time and curation rewards seemed equally promising. Sadly, it was not to continue. I'm not losing money yet, but things are still drifting downward.
A bit of background: when you vote on a post, your voting power, steem power, and slider weight are multiplied together to give a number called your rshares, which are credited towards the post you voted for (the r stands for "reward"). The more rshares a post has, the higher its payout. The whole "linear rewards" thing with HF19 means that when each post pays out, each rshare counts towards a certain number of STEEM in rewards. I'll call this reward_per_rshare.
reward_per_rshare is calculatedThere are two numbers you can look up on steemd.com: they are on the right side, a page or so down, and they are recent_claims and reward_balance. The first, recent_claims, is sort of a running average of the recent rshares that have been redeemed for STEEM [note: strictly, it is not a running average; it's a discounted infinite sum.]. The second, reward_balance, is the amount of STEEM that's sitting in the reward pool waiting to be handed out. There is a steady, constant drip of STEEM into reward_balance, but the amount that comes out changes over time.
When a post pays out, the network chooses how much STEEM to award it by setting reward_per_rshare by the this formula:
reward_per_rshare = reward_balance / recent_claims.
So the more STEEM are in the reward pool, the more gets paid out. Conversely, the more rshares that have been redeemed recently, the less STEEM gets paid out.
reward_per_rshare has been shrinking since HF19.Basically, HF19 blasted the system with a huge number of rshares. The devs saw this coming and adjusted the recent_claims decay parameters to help soften the blow, but there's only so much you can do. These new rshares came from the voting power increase and the end of the whale-voting-ban (or "the experiment," as many call it). What this means is that recent_claims has been steadily increasing since HF19.
Because of that, reward_balance has been steadily shrinking since the hard fork, and because of that, the reward_per_rshare has been shrinking as well. Here is a plot of all three since HF19 (the third plot is reward_per_rshare):
I got the data from 
So looking at that last plot, when HF19 hit, reward_per_rshare was 1.2 (normalizing by 10-11), but today, less than 3 weeks later, it's only about 0.47. So that means if your vote allocated 100 STEEM to a post on June 20, today it only allocates about 39.2.
This could be estimated by someone with more computer patience than me. To do it, you'd have to estimate the rate at which rshares are being allocated, and that would let you know where recent_claims will equilibrate. If someone wants to do this, here's some really basic sloppy math that should get you close if I've properly sketched it on my napkin:
recent_claims_equilibrium = rshares_allocated_per_day * 15.
I don't exactly know if the number is right, but rshares that were redeemed on that day (or allocated on that day?), then that number * 15 is 1.325e16 * 15 = 1.987e17. That means we're very very close to equilibrium on recent_claims, because the current value of recent claims is about 1.833e17.
Someone else will have to work out exactly what that means for the equilibrium point of reward_per_rshare; that number will depend on the rate at which STEEM drips into the reward pool, which I don't have on hand at the moment. Though I'm sure it's not hard to get.
I hadn't meant to make this post so technical, but there you have it. We're not at equilibrium yet; payouts will continue to decrease in the short term, but it looks like we might be getting to equilibrium on recent_claims fairly soon. And that's likely a good thing.