This approach is okay if you can work entirely in an environment (venv or otherwise) that is unmoored from the underlying system. But usually the reason to use an older OS is because you want to be linking to specific versions of boost or some other dependency that's a pain to build and install from source, so depending on your scenario, installing a deadsnakes python may not work if you're depending on there being a corresponding `python3-xxxx` package that links up system python to bindings for a particular library.

Unnecessary snark is unnecessary. We already did the bulk of our 16.04 -> 20.04 upgrades last summer, and were planning on mopping up the remainders over the next two months, while there was still time. That's the point of these support commitments with clearly defined timelines— allowing people to plan for this stuff to happen when it suits them.

Now we have a handful of broken support VMs and other things which have to be migrated in a rush instead of according to the planned schedule.

Yes, I think it is a packaging bug, but it's reflective of an attitude where old stuff is hung out to dry even before the officially-committed time horizons have expired. This would be fine if it were possible for distro maintainers to pick up the reins, but the pip maintainers have deliberately wrested control from them— they've basically decided that their recommended approach is for everyone to use the latest pip regardless of what interpreter they're using, especially in the case where you're using that interpreter in a virtualenv. For example on an Ubuntu 16.04 machine if you create a new venv, the system pip that gets installed there immediately runs off to the internet to check itself and then prompt you to upgrade it:

    $ python3 -m venv test
    $ test/bin/pip install pyyaml
    Collecting pyyaml
      Using cached https://files.pythonhosted.org/packages/a0/a4/d63f2d7597e1a4b55aa3b4d6c5b029991d3b824b5bd331af8d4ab1ed687d/PyYAML-5.4.1.tar.gz
    Building wheels for collected packages: pyyaml
      Running setup.py bdist_wheel for pyyaml ... done
      Stored in directory: /home/administrator/.cache/pip/wheels/2a/d4/92/cf299bdf4162957ca8126b46e913e29f76a4f17ca762c45028
    Successfully built pyyaml
    Installing collected packages: pyyaml
    Successfully installed pyyaml-5.4.1
    You are using pip version 8.1.1, however version 21.0.1 is available.
    You should consider upgrading via the 'pip install --upgrade pip' command.

    $ test/bin/pip install -U pip
    Collecting pip
      Downloading https://files.pythonhosted.org/packages/fe/ef/60d7ba03b5c442309ef42e7d69959f73aacccd0d86008362a681c4698e83/pip-21.0.1-py3-none-any.whl (1.5MB)
        100% |################################| 1.5MB 405kB/s
    Installing collected packages: pip
      Found existing installation: pip 8.1.1
        Uninstalling pip-8.1.1:
          Successfully uninstalled pip-8.1.1
    Successfully installed pip-21.0.1

But then:

    $ test/bin/pip
    Traceback (most recent call last):
      File "test/bin/pip", line 7, in <module>
        from pip._internal.cli.main import main
      File "/home/administrator/test/lib/python3.5/site-packages/pip/_internal/cli/main.py", line 60
        sys.stderr.write(f"ERROR: {exc}")
                                       ^
    SyntaxError: invalid syntax

Note that the prompt doesn't just show up in a virtualenv. The system-installed pip has this behaviour as well, and there are some packages which don't install correctly with a pip this old, so the only thing to do is manually track a working version of pip, force-install exactly that version, and ignore the repeated prompts to upgrade.

Nightmare.

I don't see why you'd keep 16.04 around

Is it common to use the system version of Python with the latest version of Pip?

Both Ubuntu 16.04 and Python 3.5 are end-of-life. Older versions of pip will work, but newer versions drop the legacy compatability. If you have an out-of-date system you can still use an old pip just fine.