This gave me pause… are you sure? HA scripts and automations have syntax and keywords and semantics… they have variables and conditionals and loops… they are executed sequentially by an interpreter and even have limited error handling… maybe they didn’t set out to define a programming language but they’ve certainly gone and checked all the boxes so that it looks and smells like one. This is akin to arguing that “python is not a programming language, it’s a configuration for a program that tells the interpreter what to do in order to execute the program.”
That said, I absolutely understand why you want to think of it as a configuration — it’s defined by a markup language intended for configs. Does it get wrapped around the axle sometimes trying to make YAML work like a programming language? Arguably yes (see “conditions” example above, just syntactic vomit), and computer scientists may be correct to characterize it as “bizarre.” But, unlike most languages, it’s very task-specific, and as a result, can be fully written by GUI. And lucky for us, the GUI is so good now we don’t have to look at the code if we don’t want to. I don’t think there’s any argument that storing automations and scripts as YAML configs is holding back the GUI from being a powerful composition interface (and is always improving). Even cooler is that if you don’t like it, you have alternatives like Node-RED and Pyscript and AppDaemon.
This WTH title implies Jinja2 powers HA’s script engine, which couldn’t be further from the truth. Speaking as an “average” HA user I would estimate <5% of my automations and scripts have templates, mostly simple substitutions. But I have many custom-defined entities that make heavy use of Jinja2 templates. While they are daunting at first, the community has been invaluable for learning how to create these entities, and HA is so much more powerful with them.
There are a few WTHs to improve the editor UI, and assisting the user with composing (and visualizing the results of) Jinja2 templates seems like a more consistent approach with better short-term benefits than rethinking the entire scripting architecture. I would urge readers to go vote for one of those.