It looks to me like PATH lists the first-generation dependencies directly from your gemspec, whereas GEM lists second-generation dependencies (i.e. what your dependencies depend on) and those from your Gemfile. PATH::remote is . because it relied on a local gemspec in the current directory to find out what belongs in PATH::spec, whereas GEM::remote is rubygems.org, since that's where it had to go to find out what belongs in GEM::spec.
In a Rails plugin, you'll see a PATH section, but not in a Rails app. Since the app doesn't have a gemspec file, there would be nothing to put in PATH.
As for DEPENDENCIES, gembundler.com states:
Runtime dependencies in your gemspec are treated like base dependencies,
and development dependencies are added by default to the group, :development
The Gemfile generated by rails plugin new my_plugin says something similar:
# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.
What this means is that the difference between
s.add_development_dependency "july" # (1)
and
s.add_dependency "july" # (2)
is that (1) will only include "july" in Gemfile.lock (and therefore in the application) in a development environment. So when you run bundle install, you'll see "july" not only under PATH but also under DEPENDENCIES, but only in development. In production, it won't be there at all. However, when you use (2), you'll see "july" only in PATH, not in DEPENDENCIES, but it will show up when you bundle install from a production environment (i.e. in some other gem that includes yours as a dependency), not only development.
These are just my observations and I can't fully explain why any of this is the way it is but I welcome further comments.