One of the factors-of-two comes from computing the first input block of the two SHA's in the HMAC calculation and re-using this. This optimization in HMAC was underdocumented, but it ought to have been used by PBKDF2 implementations.

The other factor-of-two, i.e., the 1-bit attack, comes from skipping the generation of the CBC mode IV and only generating 1 output block (160 bits) of PBKDF2 output for the key and using a later ciphertext block to check the candidate password. This saves the attacker half of the PBKDF2 work factor.

This is a weakness in PBKDF2 when used to generate key material longer than the underlying hash function output length. RFC 2898 explicitly endorses deriving multiple keys in the manner 1Password used it:

    For instance, one might derive a
    set of keys with a single application of a key derivation function,
    rather than derive each key with a separate application of the
    function. The keys in the set would be obtained as substrings of the
    output of the key derivation function. This approach might be
    employed as part of key establishment in a session-oriented protocol.

... without mentioning the fact that some of the derived keys would impose more work factor than others.