> .include "../../devel/py-curses/buildlink3.mk"
> .include "../../lang/python/application.mk"

The order doesn't matter much for "application"s, except
the indirect dependency difference you mention which is
not much of an issue imho (it didn't exist when I wrote
the python stuff, and I don't understand the inner workings
of bl3's BUILDLINK_DEPTH either).
For pure extensions (this basically means pkgs which have
the PYPKGPREFIX in their PKGNAME) the order is important:
extension.mk must come first. This is because the first
line enforces the correct Python version in case the pkg
is needed by another Python extension or application
(which has already selected its Python interpreter).
There is a little inconsistency caused by the fact that
the distutils support is located in extension.mk: Applications
(ie toplevel pkgs which don't have PYPKGPREFIX in PKGNAME)
using distutils still need to include extension.mk. In that
case extension.mk should be included after application.mk,
so that the Python version selection logics doesn't get
confused. Perhaps the distutils support should go into
a separate file, but that's more cosmetical. (And since most
Python pkgs are extensions using distutils, the current state
causes the least overhead.)

> the #!/usr/bin/env python header is not replaced by
> ../../lang/python/application.mk when I set NO_CONFIGURE=yes

That's a general flaw in the REPLACE_INTERPRETER logics,
not Python specific.

best regards
Matthias