As I said, if you bypass GUI, the tests will be more stable (because they don't care about changes in GUI), which makes them cheaper to main and faster. Running test through GUI also makes error detection much more difficult and you can't meaningfully use things like test stubs. But they obviously don't test GUI.
In the ideal situation, you'll have unit and coded integration tests to test business logic and some GUI tests to test GUI (but not business logic). It's because no type of tests can cover everything. For example, you may have a several unit tests to test a single method, because there are several things that may fail there. And there is no point in running integration and GUI tests if the individual method doesn't do its job. You can't make such granular testing with GUI tests, because you'd need an huge amount of tests, and because GUI tests are so slow, they would take too much time to execute. You also won't be able to simulate all possible situations. But unit tests are not a complete answer either - you may have all units working as designed, but not working together correctly. That's the job for integration tests. And so on.
But we don't live in the ideal world (testing tools for AX 20120 are far from perfect, people don't want to invest to tests etc.), therefore you need to make some compromises anyway. But you should have a good idea what you want to test and why, and what you won't test and why.
AX 2012 comes with SysTest framwork for unit tests, which can be used for integration tests as well. You can even manipulate form controls through X++. But if you want pure GUI tests (which handle AX as a black box), coded UI tests make a good sense to me.
