In practice, yeah. Environments are a broader concept in that there are also shared environments like your @stat, which are not exactly projects. But in casual Julia discussion when someone says “activate the project” or “create a project”, they’re usually referring to environments.
When you activate a project, you’re only telling Pkg which Project.toml to add packages to or rm them from. Julia itself uses a stack of environments to load packages from, and the currently activated environment is merely the first among them. Loading all packages from all environments in the stack would load quite a lot of (mostly unnecessary) things.
(Also, there are cases like FileIO.jl backends, where you want the backend package installed, but not loaded - but that’s pretty rare afaik.)
Of course, it would be a possible feature that Pkg could import a package as soon as we add it - I’ve sometimes wished for that - but now we have a similar feature coming from the other way around: importing a package that hasn’t been added prompts you to add it to the current environment.
This is pretty personal depending on your workflow, other than keeping the base @v1.8 environment minimal. I started out with an organization like yours, with a minimal base environment and a few different shared environments, for eg. @MLJ for machine learning packages, @Sym for symbolic libraries, etc., but found that in practice I rarely used those shared environments.
Creating new projects with the particular set of packages we currently need is pretty easy and cheap in Julia, so I always ended up with such specific folder-based environments.
The one exception is an environment I call @InteractiveEnv, that has packages like Revise, Plots, BenchmarkTools, Eyeball, etc. I add this to the end of my LOAD_PATH in my startup.jl within atreplinit, so that I can keep my base @v1.8 environment absolutely minimal while still having access to these packages in the REPL.