A "drawback" is that the metering scheme for Ethereum transactions needs to be more complicated, gas, instead of simply bytes as with Bitcoin. Computation needs to be metered, in addition to the number of bytes in the transaction. For example, a small transaction as measured in bytes, could still have an infinite loop, which would not be a problem in Bitcoin as it can't do loops, but infinite computation must be prevented in Ethereum.
Statefulness in Ethereum is an even larger advantage for developers than "Turing completeness" (which is easier to keep) as Vitalik Buterin explained:
... some Bitcoin people continue to emphasize "Turing-completeness"
when I have said multiple times that it's statefulness that is the
point. Once you have Ethereum's philosophical model (and imo, our
approach of viewing scripts as "doing stuff" rather than being
"predicates" is massively superior and vastly easier to understand for
developers), then Turing-completeness actually becomes harder not to
have than to have - it's actually tricky to figure out what
restrictions to put on recursive contract calling to eliminate the
potential for loops, and some measure of gas is required in any case
for the same reason why a block size limit is required in bitcoin.
The main effort towards a Turing complete sidechain of Bitcoin, appears to be Rootstock. Assuming "Rootstock is mostly EthereumJ glued to Bitcoin via a federated peg system", being based on the Java implementation of Ethereum suggests that Rootstock will be complimentary and compatible with Ethereum.