I don't think you are right there. The main drive for new users are the high rewards they get from posting and commenting atm. And those result from the price of both currencies. Taking away 75% from the current reward level will definitely lead to a massive drop of interst in activity.
Especially for big content creators who depend on the money.
Users being dependent on their Steem "income" shouldn't be the basis for making protocol/economic changes. Network and currency stability should always be the priority. If we're claiming to have a pegged token and the pegged token is never pegged, despite the resources being wasted on it, then we and the tokens lose credibility.
I get that people like money, but making sure content creators continue to make hundreds or thousands of dollars per week/month for publishing mostly unappealing or unpopular blog posts on a relatively obscure website isn't really a concern for me, personally. Stabilizing the economics and having a useful token for commerce represents vastly larger upside potential for both growth and value.
I think you are right with
However having a large community also is important for that.
What speaks against waiting 2-3 months till SBD is closer to 1 and the implementing it?
Nothing at all. That's certainly an option. I just happen to think that testing the robustness of protocols/parameters in extreme market conditions can provide useful feedback for decision-making.
Let's say that a STEEM --> SBD conversion is implemented and the markets quickly correct to a relatively stable peg near $1.00 after trading at 500%+ for a couple of months. I'd say that the function worked very well and could be further tested/tweaked for larger-scale adoption/use.
It's the extreme market conditions that create the pegging issues. So to me, there doesn't seem to be much sense in waiting for things to return to low volume and less interest to then test the robustness of protocols and parameters. If we can test when the market is highly active and volatile and find success, then we can mostly be assured that the new implementations could work fairly well against similar future scenarios.