Pipelines and Looms are similar approaches to managing a series of related
lines-of-development.  But let's focus on the differences.

Technically, looms and pipelines are not mutually exclusive.  A loom could be
part of a pipeline.  But it's hard to imagine a reason for doing this.

Pipelines use regular branches, while Looms use threads.  Threads are a form of
colocated branch, because they have multiple tips in a single branch.  When
Bazaar natively supports colocated branches, Pipelines will also be able to
support colocation.

For now, branches are more compatible with existing tools and web
sites, such as Launchpad and PQM.  While Loom threads cannot be viewed or
manipulated without installing the plugin, pipes are normal branches that can
be viewed and manipulated without installing the plugin.  Pipes can be
specified as URLs, and they can also be used via location aliases.

Being branches means that pipes also support individual configuration.  This
means they can each have different push, pull and public locations.

Because pipes are not colocated, switching between pipes requires the use of
lightweight checkouts.  But unlike looms, you can have multiple checkouts
in the same pipeline.

Looms store versioned information about the order of threads in a loom and
their head revisions.  Pipes don't version this information.  This means that
pipes cannot be as intelligent when deciding how to resolve the differences
between a local and remote pipeline.  I don't believe this there is a
significant need for such intelligence.  Most of the time, pipes are only added
to a pipeline, not removed or renamed.  On the other hand, it means that
pipelines don't need a 'record' command.

Pipes are also shelves-- i.e., they can store uncommitted changes.  Looms don't
attempt to provide this.  This means that some operations with pipes require
fewer steps.  It also means that it is meaningful to merge uncommitted changes
from a pipe.