Loading the ENV to the Tera context is convenient in 2 locations:

template

The template.toml itself could go thru a first transformation pass. That would allow for instance:

...
[[variables]]
name = "greeting_recipient"
default = {{ LOGNAME }}
prompt = "Who am I greeting?"

or something richer such as:

...
[[variables]]
name = "greeting_recipient"
default = {%- if LOGNAME %}{{ LOGNAME }}{% else %}Vincent{% endif%}
prompt = "Who am I greeting?"

scaffolding

I could imagine templates that can be controlled by ENV.
For instance, calling MY_MODE=prod kickstart --env . would generate a diferent output than MY_MODE=dev kickstart --env .. What happens exactly is left to the template.

I would suggest NOT loading the ENV by default for security reasons.
I would also suggest supporting a --env-key some_key or similarly named option that loads the ENV under the some_key key. Not only it allows accessing the ENV as a key/value but it also allows escaping potential collisions where both your template and your ENV could have a greeting_recipient (for instance).