I'd never use /usr/bin/env to find a shell. Just #!/bin/sh and write portable code, end of story.
The env trick is useful when you have some programming language that is not commonly packaged. Users might have it in /usr/local/bin or some completely personal place that's in their PATH: /home/joe/bin or what have you.
The git project uses shell extensively and the resulting tools are portable to just about every unix under the sun and the Git for Windows bash environment.
Their shell script guidelines are pretty helpful for someone wanting to familiarize themselves with portable posix shell scripting. There's some style nits in there too, but the other stuff can be helpful if you're looking for a well-traveled path.
The overwhelming majority of scripts with such a shebang only works on bash with GNU tools. Trying to run them on dash or with BSD tools is often impossible. When it is compatible, it often has critical bugs due to the limitations of error handling (pipefail and $PIPESTATUS are both nash extensions).
When people say "portable" they don't usually have 1997 computers in mind. Following the old spec is good to have broad support on today's machines but is not in itself a target.
A script written for Python 3.5 (which was released 7 years ago) is very portable and will even work on non-Unix platforms like Windows. If it's not there, it is easier to compile than the entire suite of Unix tools. In addition, it has proper error handling...
The nice thing about Python is that, for the most part (see below for exceptions), old 3.x code is forward-compatible to new code. So a basic Python 3 script written in 2008 should still run fine in 2022.
Exceptions:
Asyncio has been in active development and was considered "provisional" for a long time, but is now stabilizing. Asyncio code that predates async/await syntax will not run on new versions of Python (this maybe can be converted with automated tools).
Type annotations have also been in active development and was considered "provisional" for a long time, and is also now stabilizing. In a future version (maybe 3.11?) a lot of `from typing import ___` imports will break and need to be replaced (this can mostly be converted with automated tools).
Several modules in the standard library are considered "dead batteries" and will be removed in an upcoming version. See <https://peps.python.org/pep-0594/>, and for discussion <https://discuss.python.org/t/pep-594-take-2-removing-dead-ba...>. This is probably the worst aspect for forward-compatibility, but it seems necessary to ensure the health of the CPython project going forward (unless of course enterprises decide to start contributing back some faction of the billions upon billions that they make on the backs of the Python Software Foundation every year). Expect community members to spin off these libraries
It's also worth mentioning that there are "higher-level" languages than C, which produce portable-ish native binaries (modulo some dynamic linking dependencies, which isn't that different from depending on a Python or Perl runtime).
The env trick is useful when you have some programming language that is not commonly packaged. Users might have it in /usr/local/bin or some completely personal place that's in their PATH: /home/joe/bin or what have you.