If you look closely at the definition of authenticated encryption modes, you will see they all are, actually, the combination of symmetric encryption and a MAC.
Using traditional encryption and an independent MAC has a few tricky points, none of them being unsolvable:
The encryption mode will use a key, and the MAC will also use a key; using the same key may trigger unwanted weaknesses (e.g. if the encryption uses CBC mode and the MAC is CBC-MAC). Solution: derive both the encryption key and the MAC key from a "master key" through a Key Derivation Function.
The encryption uses an Initialization Vector, and the MAC may also use an IV of its own. Using the same IV for both may, then again, imply weaknesses, especially since the requirements for both IV may be distinct. Solution: use a KDF to derive two IV from a "master IV"; or use an IV-less MAC such as HMAC (that's the great advantage of HMAC: no IV; hence, it is very hard to get it wrong with HMAC).
A MAC may (theoretically) leak information about the processed data. This is the whole mac-then-encrypt or encrypt-then-mac debate. Solution: encrypt-then-mac is the "right thing" but it is easy to get it wrong by forgetting to MAC the encryption IV and/or the encryption algorithm identifier. SSL/TLS does the "wrong thing" but gets away with it because HMAC is "sufficiently different" from block-cipher based encryption.
An Authenticated Encryption mode is designed to solve these questions and do "the right thing" so that the requirements for the user are as light as possible (e.g. a single IV with just a "non-repeating" clause, not needing unpredictable randomness or uniform distribution).
Summary: authenticated encryption should not be opposed to traditional encryption combined with an independent MAC; authenticated encryption is "combined traditional encryption and independent MAC, done properly".