The library does not define the required members of class templates in case
of an error. This technique causes the compiler to stop displaying diagnostics
in client code, at the point where the error actually is, instead of tracing
template instantiations into the implementation of the library.

The library's components have limited error conditions, so problematic input
can be spotted easily.

MPL provides algorithms on Sequences, so transformations (such as turning by-value
parameter types into const references for optimized forwarding or computing
a signature to specialize boost::function
after applying boost::bind)
can be expressed more easily. The MPL Sequence concept is compatible with several
other Boost libraries (most importantly Fusion),
so another reason is interoperability.

This-pointer, this-reference or just
the object (or maybe even a smart pointer to the object) plus adjustments of
cv-qualification - all these cases have their place, somewhere and there is
no single best answer.

Special treatment of the class type within the sequence can significantly complicate
client code. A custom ClassTransform argument allows the
client to adjust the class type before the sequence is formed and then treat
all parameters uniformly.

The first one is just using more templates so every property has to be asked
for explicitly. This approach results in more complicated client code if more
than one propery has to be checked and in a exponentially larger library interface.

The second alternative is having the client pass in bit patterns via non-type
template parameters. The logic has to be performed by the client and there
are much more error conditions. Further, class templates with non-type template
parameters do not work within MPL lambda expressions and can cause problems
with older compilers.

Yes, but it isn't immediately obvious as the set of possible MPL sequences
isn't inherently disjoint from the set of callable builtin types.

However, any attempt to make a builtin type work as an MPL sequence is a bad
idea, because builtin types are accessible before the headers that make the
type a sequence have been included, which can easily violate the ODR.