Ok, I must be totally misinterpreting the nature of your reply to me because this…
sounds in my head (and if I read it outloud) like you think I’m too slow to understand.
Anyway, I’ve said what I came here to say and Frenck clarified his stance on the subject so, I’m good.
Not at all. The first quote explains the second quote.
M-kay. 
To @frenck and all others that are doing this amazing job for paid or on a free time. Thank you very much for the effort you guys have made for HA! Looking forward to see new integrations also from UI. Only thing that I really hope is that the documentation would also be updated.
Keep up with the good work!
Well, it has improved a lot already. Especially the fact that we block code changes if there is not a matching change in the documentation prepared.
This has been enforced quite a while now, and that ensures it keeps up.
However, I do agree there is a lot of other things that still need to be done. For that matter, if you see something, hit that edit button on the top right!
It is an easy way to contribute and help out 
Easy instructions here:
then you obviously have changed. thats great to hear.
a bit over a year ago you did (in discord PM), because i spoke out in a simular topic.
the decision was made long ago though. the moment that the storage directory was created first, this decision was made.
All I am reading here is bickering, accusations, and assumptions, yet those who dislike the changes not offering up solutions. Quite disappointing.
There have been some very constructive arguments made. That post however contributed nothing.
As an IT professional I will always advocate for readable, shareable and trackable configuration files.
If the change to UI-only configuration means the removal of these capabilities (which is my understanding of the post), I will review my continued use of this platform.
I understand that YAML isn’t newbie friendly for a lot of people (and don’t get me started on templating), but UI only will be just as unfriendly to a section of the current userbase.
To be honest I don’t think it would be necessary to share config if it’s intuitive in the UI. The only thing you would share is automation ideas. The rest would everybody be clicking together easily then. No need for other to go wonder around in yaml and templates to understand half of it and still have 100 questions about how to do it themselves. (speaking from my own experience)
You have to consider people wo:
I’m glad it works for you, but that is breaking lots of other people’s workflows. People who has invested considerably amount of time on it.
Thank you @rpitera for that info. I am newbie with all of this and still have to rely on a documentation almost in every thing that I am going to do with HA. I will read those instructions you linked and maybe some day (over the rainbow) I am good enough to try with those. 
About the future… @frenck …is there going to be some kind of “conversion tool” for older yaml based integrations that will provide that good old yaml to UI compatible? Or do we have to do everything with the UI from zero and what happens if the integration is not done for the UI? 
Totally agree with that. I much prefer updating configuration in readable and self documented yaml file (that can be versionned, sometimes generated, backupped, is repeatable, etc …) than navigating through a user interface. Basically in an Infrastructure as Code or Home Automation as code fashion rather than what is already doing google and apple for more basic home automation.
I can understand why some user likes a nice GUI for configuration and it’s true something has to be done to rationalize the architecture because configuration pieces start to be scatered all over the place.
I just wish we could have an option, like it was done for lovelace, to either manage everything in GUI or everything in yaml. Best of both worlds…
This is not a great way of looking at things IMO.
The whole idea is that you shouldn’t need to be a power user in order to operate Home Assistant. It shouldn’t be overly complicated to integrate your devices and services with Home Assistant. It shouldn’t require learning a markup language, spending a long time reading documentation, googling solutions in forum posts, looking up GitHub repos and YouTube tutorials, etc.
Everybody who contributes in these areas and assists the community is very much appreciated. But things should not be this difficult in the first place. Most people become interested in home automation to save themselves time and make their lives more convenient. When users are instead spending their valuable time simply trying to make things work and becoming frustrated, that’s not a great user experience, and we should fix that.
By suggesting that non-tech savvy people would be completely lost without power users to hold their hands, that shows the value of changes like this which are focused on making things easier.
If you want proof to refute your theory, take a peek at the Hubitat community forum. Hubitat’s “rules” are created exclusively via its UI; rules cannot be exported for sharing. So, are the users just sharing automation ideas and then just “clicking them together easily”?
No. To troubleshoot their rules, or to share them, they post screenshots of the rules. They also report they wish they had the ability to export them because it’s inconvenient to share them as screenshots (or only as ideas).
There’s a strong argument to be made that Home Assistant’s popularity grew because it was so easy to share everything (like the configuration of integrations and entities, automations, scripts, etc). More than one person has simply copy-pasted something, made a minor customization, and was delighted to have it work for them (sometime without having a deep understanding of what they just copied).
Anyway, this is all academic because Home Assistant’s Automation Editor has always stored automations in YAML thereby making them easy to share (and there’s not even a hint of this feature being removed). Eliminating that ability would be unpopular, to say the least.
I think we (well the frontend team and contributors, i’m pretty lost in frontend development myself) balanced that greatly with Lovelace tbh.
Thanks for explaining the reasoning @frenck, I think this post is one of the best examples of good communication between the development team and the users, especially with such a hotly debated topic.
One point from the myth busting section:
One of the problems I have with this approach is that .storage is constantly changing, and is mixing configuration and state. Instead of a clean history, real changes are often lost between things like battery level changes on mobile apps, last seen or last updated timestamps on various entities, etc…
Is there anything we can do for a cleaner separation?
Those are all stored in the .storage/core.restore_state file. I personally would exclude that file in the .gitignore in that case.
Good point, I’ll exclude it, but it’s not the only one. .storage/auth changes often (I’m guessing that can be excluded too), but also .storage/core.config_entries gets refreshed with new access tokens (and that’s definitely a file I want tracked), .storage/mobile_app (not sure if it’s a file I want tracked).