I find packages convienient.
I write a package for one room, copy it for ALL the other rooms, do a search and replace on specific strings and voila all the rooms are done.
Subsequent edits are a tad more tricky but I still copy the new working code and just update that bit.
Also when I’m having problems with “this” automation I just go to “this” package (a much smaller file)
so for example I know that my input_boolean.ib_light_bed4_timer_enable is in the lightbed4 package as is my script.sc_light_bed4_timer and input_number.in_light_bed4_timer
As the lighting levels are common to multiple rooms then the input_number.in_aalight_bed4_lvl is in aalight package
The naming ensure traceability and they are easy to find in lists as they turn up alphabetically
Yeah they have a lot of advantages, especially as configurations get larger. I have a feeling I will someday end up on them, but for now I am quite efficient on my current structure as I can still remember more or less exactly where everything is in each file just based on the chronology of when i built it.
I think some time ago the entities were called by id, and at some point it was changed and they were called by their aliases.
Took me at least half a year to debug this, but hopefully my configuration will work now 
If you’ve split your config out from automations.yaml then you also can’t edit from the UI even if you have id: defined. I find it bizarre that automation entity_id’s are generated from alias and scripts generated from id! 
Surely this need’s to be standardised?
I’ve only just noticed this as most of my automations have same alias as id, however, for the exceptions I thought something was broken this morning! 
was this ever raised as a feature request or something?
I find it really confusing - especially as if you first create the automation and then change the alias,
the entity_id does no longer change, but stays the same as initial one …
Can be really confusing if you have old automation and cannot guess any longer where their entity_id is coming from
I find confusing too the fact that friendly name (possibly localized) for automations come from alias and also a programming identifier as entity_id come from alias. If I want use longer, localized display name for automation I need to add a customize section in source file, elsewhere, far from where the automation is defined. Very error-prone and difficult to maintain. Hope something changes.
Should this answer perhaps be updated to say that the ID isn’t only to allow editing, but it also enable traces for debugging?
This is not 100% correct, i set an ID but it is still not editable in the UI because i do not use the automations.yaml but seperate files for my automations and include them.