Not a hundred percent correct, but very close. 
You won’t need the automations and script keys in configuration.yaml. The UI does not offer the possibility to change things, if you have them configured in yaml files. The automations.yaml will be created by the UI, if you created an automation in the UI, but it is not necessary at first. The system will create it, if needed.
@AleXSR7001
You might want to take a different look at these files, more technically. I’ll try my version of explanation, maybe this offers some different insight. 
The main part of HA are “domains”. These are the upper most configuration levels and need to be defined in configuration.yaml, if you want to use an “!include” approach. These are eg. light, script, automation and so on. This is not about integrations, as these as well use the same domains as we did ourselves in configuration.yaml. Integrations don’t invent new domains (normally), they use the ones from HA. Eg. the HUE integration uses the light domain for the bulbs it controlls, or the switch domain for switches and so on. Or you take a weather integration, it uses the weather domain, and maybe some sensors under it.
As stated before, this can get very un-readable, if you have a bigger installation or better if you have a lot of different devices, sensors and… To avoid this, you can place complete domains in other files and link these files in configuration.yaml. Eg. light: !include my_lights.yaml.
Technically this is nothing fancy. The file configuration.yaml gets parsed, and if it finds some excluded files, it just takes these files and parses them exactly where they are noted. In the end, for the system to work with, it is one big configuration.yaml that is presented to the system.
This is the way you would wanna go, if you have your things sorted by domains. This is useful for some installations, especially if they are not too big.
The other way is the approach by packages. Packages offer the possibilty to group things, eg. for a room or something that is almost always used together. Eg. I have a weather package, where I have everything weather related configured. My weather provider (accu_weather) as well as all automations regarding weather (close the windows notification, if an alert comes in / close the covers if it rains), the used helpers (input_xxx), some template sensors and so on. If I need to take a look for something weather related, I know where to find it.
You get the idea 
What the system does in the background is different to an !include in configuration.yaml. It takes the package file apart, and sorts it into the specific domains that are used.
To sum that up: packages are one of two ways to include and group/order things. One way is the domain approach by including domains via a file. The other way is to break things up and put them in to content related packages. It is just a different approach to include something. And the “!include” files is something that can get very un-readable as well. Assume you have a hundred lights over different rooms, you’ll never find the specific light you’re searching for.
But let me give you a recommendation, as I’m mostly using packages. Don’t clutter it to much! It is not useful, to divide things to their deepest level. Use something, that is easy to remember for you. Put all things together, that fit together - nothing more, nothing less. But don’t use it in a “company” approach, use it more like a group approach. In my presence detection package is everything that has to do with it, even the frontdoor sensor, the light to turn on when coming home and so on. “Thematical diversion” if you will
###############
#
# base package
#
###############
homeassistant:
customize:
person.steffi:
picture: /local/pictures/steffi.jpg
entity_picture: /local/pictures/steffi.jpg
person.patrick:
picture: /local/pictures/pat.jpg
entity_picture: /local/pictures/pat.jpg
climate.livingroom_ac:
hvac_modes:
- 'off'
- 'cool'
- 'dry'
- 'fan_only'
swing_modes:
- 'off'
- 'vertical'
sensor.livingroom_average_temperature:
icon: 'mdi:thermometer'
sensor:
- platform: systemmonitor
resources:
- type: processor_temperature
- type: processor_use
- type: memory_use
- type: disk_use_percent
- platform: uptime
- platform: time_date
display_options:
- 'time'
- 'date'
- 'date_time'
- platform: sun2
entity_namespace: sun2
monitored_conditions:
- solar_midnight
#- astronomical_dawn
#- nautical_dawn
- dawn
- sunrise
- solar_noon
- sunset
- dusk
#- nautical_dusk
#- astronomical_dusk
- daylight
- civil_daylight
#- nautical_daylight
#- astronomical_daylight
- night
- civil_night
#- nautical_night
#- astronomical_night
- elevation
- min_elevation
- max_elevation
- platform: template
sensors:
friendly_day_of_week:
value_template: >
{% set dayofweek = (as_timestamp(states('sensor.date')) | timestamp_custom('%a', true)) %}
{% if dayofweek == 'Mon' %}
Montag
{% elif dayofweek == 'Tue' %}
Dienstag
{% elif dayofweek == 'Wed' %}
Mittwoch
{% elif dayofweek == 'Thu' %}
Donnerstag
{% elif dayofweek == 'Fri' %}
Freitag
{% elif dayofweek == 'Sat' %}
Samstag
{% else %}
Sonntag
{% endif %}
friendly_date:
value_template: >
{{ (as_timestamp(states('sensor.date')) | timestamp_custom('%d.%m.%Y', true)) }}
friendly_day_and_date:
value_template: >
{{ states('sensor.friendly_day_of_week') }}, {{ states('sensor.friendly_date') }}
binary_sensor:
- platform: workday
country: DE
province: BY
workdays: [mon, tue, wed, thu, fri]
excludes: [sat, sun, holiday]
- platform: sun2
entity_namespace: sun2
monitored_conditions:
- elevation
- elevation: 3
- elevation:
above: -6
name: Above Civil Dawn
script:
nothing:
sequence:
- delay: '00:00:01'
nothing_light:
sequence:
- delay: '00:00:01'
automation:
- id: Create All Lights Group on Startup
alias: Create All Lights Group on Startup
trigger:
platform: homeassistant
event: start
action:
- service: python_script.create_group_all
data:
domain: light
group: all_lights
group:
all_windows:
name: Alle Fenster
entities:
- binary_sensor.bathroom_window_contact_on_off
- binary_sensor.bedroom_window_contact_on_off
- binary_sensor.guesttoilet_window_contact_on_off
- binary_sensor.kitchen_window_contact_on_off
- binary_sensor.diningroom_window_contact_on_off
all_doors:
name: Alle Türen
entities:
- binary_sensor.livingroom_balconydoor_contact_on_off
- binary_sensor.garage_garagedoor_contact_on_off
- binary_sensor.hallway_frontdoor_contact_on_off
- binary_sensor.garage_backdoor_contact_on_off
And to make things a little unclear again: if your installation grows, you’ll find yourself including domains in configuration.yaml and using packages together.
Hope this helps as an addition to what @finity already explained very well!
