I originally implemented Jinja2 on App Engine using the examples shown on the App Engine site here: https://developers.google.com/appengine/docs/python/gettingstartedpython27/te
I had the same question, but the answers here do not satisfy me.
I think it's about encapsulation vs performance. For a small application you can have a global, no problem. So the first solution is just fine. It lets you solve an easy problem in an easy way, without the overhead to learn the details of a framework.
For a bigger application you probably like to encapsulate and bring some order into your objects. Basically you make a framework, an infrastructure for scalability. But that's what webapp2 is supposed to give you.
The basic problem behind it: If you decide to make a singleton type of object local to a class that gets instanciated and freed as part of the logic (like webapp2.RequestHandler classes in official examples), then that referenced object (jinja2) will be released when the last class instance is gone... you might get a lot of freeing and reallocating. So its good to have a link to an object somewhere (webapp2.registry) to prevent removing even if not referenced anywhere else. It's like global, but without poluting the global namespace, and it is accessible from everywhere through webapp2.get_app().registry. It's also caching. Then, with cached_property you do just another layer of caching.
In short: If you want to encapsulate you better add caching for your app to stay efficient
In this case you go for the webapp2_extra jinja2 and in every module you can access the same jinja environment with:
jinja2.get_jinja2().environment