I am glad if you’re asking sincerely.
It is because, the Email-chat standard is the only chatting alternative with the potential to communicate seamlessly with billions of existing email accounts.
I keep looking at deltachat because I currently don’t know another freely available “reference implementation”, because the seamless interaction with the email world is a crucial feature, and the early versions clearly realized this and development followed this direction.
I know that implementing seamless fully compatible email interaction and adaption options may seem not that easy, not immediately necessary, or even unfamiliar (NIH), e.g. if looking with a “messenger developing driven focus” rather than at the larger picture.
I also know that solving the seamless-interaction problem isn’t the most straight-forward kind of thing possible to solve in a single iteration for every use-case. But I am sure it is possible, with a moderate amount of work in the wiki, the design, and implementation, it will bring very fruitful results. For that I had started the use-case and imap wiki pages, a place to condense requirements and options into a coherent solution, adding to it whenever a new aspect come up. By now the wki pages provide a really good basis to discuss questions, and come up with simplifications and roadmaps. With the multi IMAP-push already implemented there are actually only a few aspects missing, to have a solution that already covers all the stated requirements.
Wanting to cut down and concentrating efforts is also understandable for the project lead, but a bad thing if this means basic fundamentals are not solved properly. Not really solved fundamental problems and errors behind imagined lines and workarounds will always come up again, just that later-on these type of things tend to get harder to solve and grasp, not only because users don’t see the whole picture if pressed into workaround implementations (missing full email-compatibility, and the smallest optimal set of use-case adaption preferences).
The natural absence of the focus on the code and coding work is why regular users sometimes see problematic consequences of some of the development decisions faster than those that have already thought more about it. In the case of the removal of the “invite friends” feature, I only filed the re-enablement issue on github after seening responses in the thread here. I considered the re-enablement a non-controversal issue, a trivial and logical decision to just revert the removal. IMHO the usefulness of the feature simply got overlooked when removing it (better template can help users in reaching out e.g. to existing groups). Who would remove a feature that is of help to users. It actually looks as if it somehow only got removed by mistake, due to a bug report that was actually about deltachat not yet allowing to pass message-sending-intents to new (to-be-created) contacts (https://github.com/deltachat/deltachat-android/issues/429).
You’re right on another thing as well. For everybody that is interested in backwards compatible Email-chat, the current “streamlined contact requests” seems “wrong” (suboptimal). Because having a default max. length value instead, should enable a much better default chatting experience (see this comment). While it also provides full compatibility to receive new short-message chat attempts from known contacts with standard email clients, and reduces the amount of prompts shown to the user. So it is certainly another good small step worth to implement.