There are apparently at least two known (potential) drawbacks (from this (1) Team blog):
Obviously this can cause potential problems for any legacy systems which weren't designed to run against a MARS enabled design - "existing code optimized to run in the non-MARS world may show a slight performance dip when run un-modified with MARS"
“With MARS you can send multiple multi-statement batches to the server. The server will interleave execution of such batches, which means that if the batches change server state via SET or USE statements, for example, or use TSQL transaction management statements (BEGIN TRAN, COMMIT, ROLLBACK), both you and the server can get confused about what your actual intent is.”
I've yet to try out a MARS enabled design, but I'm coming very close to doing so on my current project. We have a slight issue with competing (and sometimes dependent) query operations (like lazy loading configuration data out of the same database that an active recordset is executing).
There's more information on the MSDN site (2) here