What does "activating the ESP-IDF environment" (. ./export.sh or source activate_idf_v6.1.sh) do, and why must it be repeated in every new terminal?

Question

Accepted Answer

It sets environment variables in the current shell: IDF_PATH, the cross-compiler and tools on PATH, and ESP-IDF's Python virtual environment. Environment variables die with the shell, so each new terminal starts without them.
After installation, the Xtensa compiler, idf.py, esptool and the rest sit in private directories under ~/.espressif that the system does not know about. Activation is what makes them reachable:

PATH gets the toolchain and tool directories, so typing idf.py or xtensa-esp32-elf-gcc finds the right binary.
IDF_PATH tells the build system where the framework source lives.
The Python venv is activated, so idf.py runs with the exact package versions ESP-IDF installed.

This is why the command is sourced (. or source) rather than run. A script started normally runs in a child process, and its variable changes vanish when it exits. Sourcing runs it inside the current shell, so the changes stay. They still last only for that shell session, so a fresh terminal shows idf.py: command not found until you activate again.
ESP-IDF does this deliberately rather than editing your ~/.bashrc. You can keep several versions installed and choose per terminal which one is active.
Tip: idf.py: command not found almost always means "this terminal was never activated", not a broken install.
Go deeper:

ESP-IDF — Installation on Linux — setting up and activating the environment.
 Wikipedia — Dot (command) — why . and source run a script in the current shell instead of a child process.