1. Massively increase complexity (read: attack surface).
Handling arbitrary IP packets, tracking their state and handling their responses is complex. Many operating systems over the years have had serious vulnerabilities in their various network stacks, if Tor implemented their own this would likely result in a series of similar vulnerabilities. See:
Linux: CVE-2016-2070, CVE-2015-5364, CVE-2015-1465, CVE-2014-3673, CVE-2012-6638, CVE-2012-2744, and many, many more.
Windows: ms09-048, ms10-009, CVE-2013-0075, ms13-018, CVE-2014-1811, CVE-2009-1925, MS14-031, and many, many more.
And that's not to mention the difficulty of now implementing some kind of exit policy enforcement which would involve further parsing and classification of the packets in a stateful manner!
How do you discern who should be the recipient of specific types of packet? Could you trick the Exit to return another users traffic to you?
2. New types of abusive traffic for operators to deal with.
If entire IP packets are encapsulated then that necessarily includes the source IP address. Should Tor act like a NAT and rewrite the source, or allow exits to become participants in DNS reflection attacks? What about IP fragmentation as a means of by-passing stateless packetfilters?
Similarly a "bad" exit has new, fine-grained ways to attack the clients various network stacks by sending response packets. This opens up new options to deanonymise or exploit tor users.
TCP/IP stacks require state. State identifies you as it changes over time. Full packet encapsulation mean the state that comes out of the other side of the connection is the same as your local state.
TCP and IP and UDP all have various options that can be on or off or specific values. These are implementation and context specific. Tools like lcamtuf's p0f can determine your operating system and even version of operating system by looking at only a few packets. Currently with Tor, this is the exit or onion services operating system, if the full packet was encapsulated, it would be yours. This might allow you to be tracked across sessions, as it currently does with VPNs.
For example if you're the only user with a specific TCP fingerprint in your incoming TCP handshake to the VPN, you'll be the only user coming out of the VPN with that fingerprint in your TCP handshake.
4. Tor isn't magic
You can't just throw all your traffic at Tor and say "make me anonymous", anonymity doesn't work like that. VPNs lack context, they route all traffic over a single path, this means all your traffic is linked together. You may not want your "anonymous" browsing traffic to be taking the same circuit as your ssh connection to your personal webserver, this would link together your "anonymous" browsing and your identity.
For it to be used effectively it would need to provide some means of providing it context to isolate different applications or denying specific applications. If you don't, you will contaminate identities and potentially deanonymise yourself. There is currently no good way to do this outside of specific configuration of distinct applications.
Ultimately I think it's a dangerous idea that Tor should be very, very careful with if implemented. Not implementing it would be far easier and safer for both clients, and exit and onion service operators.