The change in naming convention for our Chef products is to clarify what we feel is the best use for each of our core products. Chef Infra for infrastructure-as-code, Chef InSpec for compliance-as-code, and Chef Habitat for application automation. LarryC is right that marketing is part of the reason, as you pointed out Chef has been viewed and only placed in the infrastructure-as-code section of most tooling diagrams. It is our intent to align public perception with our assertion that is that Chef Habitat is the best method of packaging, deploying, and maintaining applications. That doesn't mean that you can't use Chef Infra to deploy and configure an application; it just means that we have a better tool that focuses on packaging the application code with its dependencies into an immutable artifact that allows you the power to deploy it to almost anywhere. Add to that the ability to automatically manage dependencies and transitive dependencies and you have a very useful framework for modernizing applications and their lifecycle.
I understand that you have complex applications that are deployed and configured with Chef cookbooks. I think that if you dig deeper into the pattern of using cookbooks to define the underlying infra and Habitat to package and deploy the app, you will find it is less painful than using cookbooks for everything. I hope you will find Habitat's use of app lifecycle hooks and ability to orchestrate a real advantage over the traditional Chef way to manage apps.
If you are considering Habitat, I would encourage you to take advantage of our recorded Webinars and the free learning content at https://Learn.Chef.io and get your hands on the keyboard and explore the possibilities provided by Habitat.
Thanks for your use of Chef and I hope that this helps you understand our new direction a little better.