I have read what was written since the initial post by SFY_labs and will provide a few comments from a perspective of a dev who worked on dApp staking from the idea to the architecture, implementation and the docs.
(this isn’t necessarily the stance of the Astar team but it is mine)
First, I have to commend @you425 for doing an analysis, modeling and explanation. It’s refreshing to see someone take in-depth dive at something, especially related to tokenomics. 
Discussions tend to be “echo chambers”, but this was something new & thought out.
Tier System
From all the discussions I can see, everything seems to be working as intended.
Tier system was explained over a year ago, so calling it absurd or nonsensical is “absurd” in itself.
Tier system has a purpose, as does resetting the staked amount.
It’s all explained in the original post, in the tokenomics post(s), in the official docs.
Rewards & Price
I’ve commented it here, but to repeat, ASTR price has increased roughly 3-4x in the last 4 months. The amount of rewards received by the developers has also increased by the same factor - however, this hasn’t been mentioned once in the discussion so far.
For easier reference, here’s the breakdown of rewards per tier:
Tier 4 rewards are meant to be entry level, they are supposed to be meager.
Tier 3 rewards are meant to be much more substantial.
For a well established project, with a solid (and loyal) user base, achieving tier 3 (or 2) should not pose a significant challenge.
And to repeat what I wrote in the linked forum post, it’s expected that developers will stake on their own dApp. It’s web3, it’s decentralized, there’s no mechanism to prevent this (and why should we?). Rewards for tier cannot be so high that they’re enough to keep buying higher tiers, and also support the development. There has to be a balance.
Parameters
One thing that is planned, and expected with every new major feature, are tweaks & updates. We can assume a lot, analyze, make models, tests, simulations, explanations, but in the end, what matters is how it works “in the field”.
We are observing how it’s working, and will continue to do so.
It’s still super early, and some time will need to pass before we have sufficient data.
Situations like this are part of the observation.
However, dApp staking is bigger than one app, and many different factors need to be considered. Just because on dApp is dissatisfied, it doesn’t mean something needs to be changed immediately or that there’s something inherently wrong.
Hybrid Solution Proposal
For the solution proposed by @you425, I really like the approach, effort and mentality here. I’m repeating my commendations right now 
.
It’s not clear to me how would you define total number of dApps that the protocol can support? This is very important, since based on this proposal, dApps are almost always in between the the starting & ending point of the line.
The system should not"punish" dApp A when dApp B increases its stake amount. I don’t see how you can achieve this without extremely reducing the amount of dApps that protocol can support.
Inflation Comment
The reduced inflation does not only benefit stakers, but every token holder.
If a developer receives ASTR as reward, that also makes them a token holder.
I’m stating the obvious here, but it’s important to keep that in mind.
Future Work
Right now, the concrete planned future work is to get tier configuration recalculated more often, and to introduce more dynamic pricing (via oracle).
The other part is the aforementioned observation.
Based on that, we’ll be adjusting parameters & logic.