I'm sorry to hear you see it this way.
Let me tell you this - changing the kubernetes manifests for dozens of deployments from Ingress to Ingress route is no fun. I wish that there were an easier path. They do provide Traefik Migration Tool that easies the pain somewhat, but even then it is not ideal. So I totally hear you.
However, I also understand their reasoning. Breaking backward compatibility is a huge pain for the end users. In most places in the industry this is a big no-no. For example, in Microsoft world, products such as .Net framework and Powershell, carry tonnes of sub-optimally designed "features" that are left there just for backward compatibility reasons. It's not uncommon to ask developers to "finally fix" something because everyone agrees that currently it's not ideal, and hear back, "sorry we cannot, because we have to be backward compatible".
Putting on a developer hat, I tell you that this is as frustrating. I often see that my product would work better if I designed it a bit differently. Or a lot differently. And I often want to go back to drawing board and to re-implement things to make them, easier, better, more stream-lined. In a business enterprise context I rarely have this opporunity. Why? Because it's cost in-effective, there is already something that is working and it costs less to keep band-aiding it, rather than do a major rewrite.
Traefik team decided that they've learned enough from the v1, that it warrants such a re-design. They saw what worked and what did not. In particular the idea of router, middlewares and services, is something that became obvious only after a lot of feedback about the v1 model has been gathered. Also when the developers wanted to implement or fix something that was tricky because of v1 design shortcomings - that informed their descision to switch to new approach too.
They blogged about it, you probably can easily find those blog posts if you are interested in reading them.
In short, in order to switch to a new design, they had to make many things work differently in traefik 2. And this is what you are experiencing.
In particular, customer experience with Ingress was not that great, configuring things via labels were a pain, so they decided to improve that via CRDs, which is, in my opinion a very logical thing to do. You simply cannot model everything that Traefik has to offer within constraints of Kubernetes Ingress object. This means that focus of the development now shifted to CRDs, which is also undestandable, there is only so many things you can do and only so many hours in a day, so it clearly makes sense to invest in the better and more flexible system that in the older one, that is being phased out.
The good thing is, that there is no big pressure to switch from v1, at least not right now. You can plan and execute that migration at your own pace. They did acnowledge that the situation with http redirect needs to be improved, since a lot of people voiced that, they did not say what their solution is going to be but they are aware of the complaint and would like to make improvements.
