It's not optional. It's required for things to work properly.
A basic example of something that would break if the environment is not activated is binaries, like mypy.
You have a script that calls "mypy"? Gotta be in the virtual environment to invoke it, otherwise the executable might not be found, or worse, it might run another executable.
It's absolutely not required, I assure you. If you run the Python binary inside the venv you have the same environment as if you'd activated the venv, but only for that execution and not affecting your shell. Try making a venv, running python, and looking at sys.path.
I assure you 100%, it is required for everything to work, it's not just here for the show.
One of the thing that the virtual environment does is modify the PATH to lookup executables from the virtual environment first.
This is to ensure that when a script calls binaries like mypy/python, it's going to find the same binary from the environment it's currently running in.
Typically if the environment is not activated, python is going to lookup to /usr/bin/python and might be something else.
This is most noticeable when there are different versions of python on the systems and when having scripts that invoke themselves.
I see we will not agree, and this thread is mostly dead anyway, but for posterity: it sounds like you haven't installed mypy into the venv you're using. I can see how that would not work. I don't try and reference python scripts that I haven't installed using the venv so perhaps that's why I've never encountered this situation. If it's part of my project it's installed into the venv (and if it's a dev dependency like mypy, which I do use, it gets installed as a dev dependency so it doesn't end up in releases).
A basic example of something that would break if the environment is not activated is binaries, like mypy.
You have a script that calls "mypy"? Gotta be in the virtual environment to invoke it, otherwise the executable might not be found, or worse, it might run another executable.