I can tell you how I see them from my user perspective, on the two accounts I have.
This account has had no missing days of posting after HF20, but I was lucky to post my daily post before the hardfork took place, and the next one after the negative RCs issue was fixed, the next day.
It took about 4 days to slowly return to normal voting patterns while voting mana was replenishing.
On my second account, where I post my actifit results, things took a few more days to get into normal behavior, because the account only has the minimum Steemit delegation of 15 SP. But after the 10x RCs update, I no longer had any issues using that account.
On my second account I create the actifit results posts daily and I follow the votes of my main account. What I don't do, except rarely, is comment.
Right now, if I look at the RC mana of the alt account it is at 98.95%.
The RC mana of my main account is almost always at 100%, much like it was with the old bandwidth system.
So, for my two accounts, I no longer check my RC mana. Ever! Because I always have enough.
Others may not have enough for the way they use their account, and that's a different discussion. One that revolves around the concept of a freemium model.
If you check Beempy.com historical stats for resource costs, you will see most costs are still going down as we speak, apart from that for claiming a new account, which for now has stabilized around 5,000 G RC = 5MM in Steemd).
A look into the future
So, one of the most marketed points of HF20 was that it will speed up the onboarding process.
That's yet to happen, but there are a few reasons for it.
This is just a speculation of mine, without any hard facts or information, but some major accounts may be waiting to make sure the cost of claiming a new account has stabilized. For example, if they would had claimed some new accounts on 30 September, it would had costed them roughly 3 times more RCs than the cost now, and they aren't cheap at all.
There's of course the little code that needs to be tested and even more, rules they need to have for potential users they want to sign up. They can't just allow, for example, one person to create 10 accounts at the expense of their RCs. If that person wants 10 accounts, s(he) can have them, but using the normal paid process.
Once these elements begin to align, more projects will start onboarding people for "free" and speed up the process.
Another reason for adding the possibility to create account using RCs instead of STEEM, was that the total number of STEEM only permitted for a small growth in user base, while blocking more and more STEEM and taking it off the market.
With the option to create accounts via RCs, which is a renewable resource, the option to scale up the user base is real, all while permitting enough STEEM to be traded freely on the market.
What I've mentioned about improving sign up process should be in the close future and can happen without constraints about future Steem blockchain development needs, so before the next probable hardfork, which is due in March for SMTs.
If you remember what I've said in the first part of the post, is that I almost never use any significant part of my RCs.
In that way, can this be balanced, in a manner that someone who needs more RCs can get them and I earn something too, because yes, I earned that amount of max RCs.
And the answer is yes, and that was the planning all along.
There are in development as we talk now, for the SMT project (so they will go out with SMTs) the so-called Delegation Pools, which will allow people to delegate away part of their RC "stake", much like they do with the SP delegation, except by delegating RCs they will keep their vote worth given by the SP.
This quote from 
Delegation Pools (#2761) are our solution to this problem and helps solve two important challenges when it comes to on-boarding new users.
Delegation Pools will allow an account to delegate just RCs to a pool and then oversubscribe that pool to users. When not oversubscribed it will act a straight RC delegation. The oversubscription won't allow more RCs to be used than delegated to the pool, but will allow greater ceilings on users. For example, I can delegate 500 SP to the pool and then allows 10 users to use up to 100 SP each. The pool will not allow more than 500 SP of RCs to be consumed, but if the pool has RCs available, each user could spend like they had 100 SP. Currently, a lot of SP is wasted on delegations because the stake is not active. This will allow more effective allocations of resources.
Note: I say SP here as an understood unit. Delegation Pools only confer RC rights. Voting Power is unaffected.