What's wrong with doing this all in one transaction that requires signatures from both parties to be valid?

Certainly it is part of the same transaction.  Let us adapt the example from the Smart Property thread:


Definitions

previous-txout 0: "smartcoin", standard send-to-pubkeyhash, nvalue==1
b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c,0

previous txout 1: normal transaction, standard send-to-pubkeyhash, nvalue==100000
7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730,0

smartcoin seller
        pubkey for to-be-sent smartcoin (CK)
        pubkey destination for smartcoin payment (SK)
        smartcoin required price (P): 100000

smartcoin buyer
        pubkey for to-be-spent payment (PK)
        pubkey destination for smartcoin (BK)


Round 1, smartcoin buyer and seller agree on a transaction

Presumably the smartcoin seller has <somehow> advertised for sale smartcoin b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c,0 at price P.

Presumably, the buyer knows how to create a standard 2 txin, 2 txout format transaction that the seller expects.

The buyer and seller communicating this basic information is outside the scope of this discussion.


Round 2, smartcoin buyer creates incomplete TX, sends to seller

txin 0 (smartcoin transfer)
  prevout (b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c, 0)
  scriptSig = zero-length (null)

txin 1 (payment transfer)
  prevout (7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730, 0)
  scriptSig = <PK-derived signature> <PK>, SIGHASH_ALL

txout 0
  nValue = 1
  scriptPubKey = OP_DUP OP_HASH160 hash<BK> OP_EQUALVERIFY OP_CHECKSIG

txout 1
  nValue = 100000
  scriptPubKey = OP_DUP OP_HASH160 hash<SK> OP_EQUALVERIFY OP_CHECKSIG


Round 3, smartcoin seller signs TX, and broadcasts completed TX to network

txin 0 (smartcoin transfer)
  prevout (b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c, 0)
  scriptSig = <CK-derived signature> <CK>, SIGHASH_ALL

txin 1 (payment transfer)
  prevout (7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730, 0)
  scriptSig = <PK-derived signature> <PK>, SIGHASH_ALL

txout 0
  nValue = 1
  scriptPubKey = OP_DUP OP_HASH160 hash<BK> OP_EQUALVERIFY OP_CHECKSIG

txout 1
  nValue = 100000
  scriptPubKey = OP_DUP OP_HASH160 hash<SK> OP_EQUALVERIFY OP_CHECKSIG


Discussion

Potential attacks, neither resulting in a direct loss of value:

• Buyer may stall or refuse to send incomplete transaction (wasting seller's time and DoS'ing an issue, if the seller prevents other buyers from attempting purchases in parallel)
• Seller may stall or refuse to send completed transaction (wasting a buyer's time and leaving the fate of their coins unknown)

SIGHASH_ALL is the default which is why it's not mentioned. There are descriptions of the SIGHASH flags in the theory section of the contracts page:

   https://en.bitcoin.it/wiki/Contracts

could this be used for mixing? p2p style like ab boss?
edit: 

you mean here: https://bt.irlbtc.com/view/106373.msg1267002#msg1267002

seems like it would take a lot of mixing as the two partners are always linked

You do mixing in rounds, each time finding some random partner. Amount of entropy you get in the end depends on how many honest partners (i.e. ones which won't rat you out) you met, but "FBI agents" do not decrease your entropy.

So you get optimal mixing when you've mixed with everybody. But since it's stochastic, you cannot know for sure. But as a rule of thumb, if you do N rounds with N participants you'll some good mixing, not optimal, though.

If we want to make it more efficient we can add a facilitator. He doesn't need to be trusted. Instead of submitting your transactions to blockchain you will submit them to facilitator. He will create a large transaction with all inputs and all outputs. Each participant can check whether his output is in that large transaction, and if it is, he will sign his input.

So you can do large number of rounds, say 1000 or 10000, without adding any additional strain to blockchain.

"Colored coin" ArmoryX p2ptrade was able to create its first atomic coin swap transaction: http://paste.lisp.org/display/134280

So implementation is here. We only need to create a good front-end now.

Technically speaking simplest ripple transaction A->B->C does not require any special handling: A will use B's offer to send money to C. C is receiving party, he doesn't need to sign anything. And only two colors are involved (A's and B's).

Bigger chain (A->B->C->D) might involve more than two colors.

Well, yes, you're right. Usually C would have pre-signed a credit line to B, but that's not really necessary.
In two phase ripple C signature is required so that A can demonstrate that he has paid and C knows it. But since the chain is public, not necessary neither.
So, yes, as you say, the simplest colored coins ripple transaction only needs two colors.

I wonder if that would be possible in a decentralized way, too? Atomic coin laundry...