"Activating Virtual Environment" means (or at least includes) adjusting the current interactive shell (e.g. its prompt) somehow. .VENV/bin/activate is a script containing shell code to do so.
A shell can only adjust itself; this is why normally you source the mentioned script directly. See What is the difference between executing a Bash script vs sourcing it?
By putting source .VENV/bin/activate inside another script and running it with bash venv.sh (or even with ./venv.sh, if set up right), you create an additional bash process that interprets the script. The process is not your current interactive shell, it sources the original script, configures itself and exits. Your current interactive shell is unaffected.
With source venv.sh you make your current interactive shell interpret the shell code inside venv.sh. Then the only uncommented line there (source .VENV/bin/activate) makes the shell interpret the code from .VENV/bin/activate, so everything works.
Creating an additional script you need to source anyway seems overcomplicated. If you want to type less, consider defining a function (in ~/.bashrc):
acti () { source .VENV/bin/activate; }Then just run it: acti.
Note .VENV/bin/activate is a relative path, so the function will properly work only in some specific directory. Maybe this is by design (i.e. the original script expects you to be in this exact directory when sourcing it), I don't know; but if not, then consider using the absolute path of the activate script.