In the suggested approach there's an owner of the full private key, who then can share this private key
so that "m of n" transactions can be made, but he still can use the whole private
key to spend the balance himself.
They note in the paper that it's possible to do the dealing step in a distributed manner where no one party learns the key (indeed, the proposed protocol does something like that internally for sharing shares of the ECDSA nonce) but they don't go into detail about it. I think any practical implementation would want to do this simply due to the difficulty in obtaining a single device whos security you can be confident of...
The differences I'd make between this and multisig is that it requires a synchronous protocol to both establish keys initially (assuming a distributed dealer) and to sign. E.g. it might be harder to make a signature using N offline wallets as you'd have to shuttle data back and forth to the offline wallets multiple times. It's also harder to 'show' that an address is multisig— e.g. for the purpose of making your policy public, though I'm not sure how much this matters since you can 'fake' multisig too. It also requires a more complex signer software. On the plus side it's much more efficient in the blockchain, esp with high N, and the transactions are indistinguishable from non-multisig which is good for privacy.