sbuild and pbuilder have developed over the years to have nearly identical functionality, and as features are added to either, they tend to be quickly adopted by the other.

As Debian packaging is a policy-driven format, it is a significant aid in determining whether a given build issue is a bug in the implementation of the builder or a problem with the package being built to have multiple implementations of a build system. In order to maintain this, the leading build systems must all have strong partisans supporting them, in a spirit of collaborative competition towards ensuring that we have the most correct available implementations of policy.

The internal mechanics of sbuild and pbuilder differ considerably, so precisely which packages are pulled to satisfy build-dependencies or how they are pulled, the precise mechanism by which the various targets in debian/rules are called, etc. may differ, causing some slight differences in behaviour in very specific cases for certain packages. Most of the time this represents a bug in one or the other implementation, and sometimes reflects a lack of clarity in packaging policy: in any case, behaviour changes ought be resolved.

Official buildds in both Debian and Ubuntu use sbuild (although often not the sbuild available from the archives), which is considered an advantage by some developers, as they have greater confidence that their configuration matches that to which their package will be exposed when built, although if everyone does this, we lose the ability to distinguish bugs in policy from bugs in sbuild.

Historically, my understanding is that pbuilder development initially focused on the needs of the developer as end-user and sbuild development initially focused on the needs of buildd and archive adminstrators. Recently, these focuses have switched, as people have built archive management systems based on pbuilder, and more helpful developer tools using sbuild.

Both tools (or their commonly available close derivatives) support storing chroots as tarballs, unpacked on the system, in separate volumes (with available hooks for special mounting: e.g. LVM snapshots), using overlay filesystems, using copy-on-write semantics, etc. Both tools offer trivial command-line tools to streamline the common case (test-build a package) and rich hook semantics to support complex cases (large archives). Both provide a means to create a test environment in a chroot. In short, both tools provide just about anything you might think you wanted in a package building tool (and both have active upstreams happy to accept bugs and patches).

In summary: if you're happy with pbuilder, keep using it. If you want to play with sbuild, feel free. The best tool is the one you are comfortable using for the sort of work you do.