Those are just different tests, and you need both, to improve your chances to reveal some flaws. The more the better. That would be enough to wrap up the complete answer, but let's think what would be the background of these two different approaches.—SA
The application has some inner layers (data layer, business, whatever) and the UI. To put it simple, some universal part functionality (libraries), application-specific layers with application-specific data model and business layer are inner layers, and UI just on top of it. You can have some flaws on inner layers which might be polished out on the UI layer: some functions are never called, or called only with more limited set of parameters. That may hide some actually existing problems in inner layers. So, testing with "real" UI won't reveal these problems. But apparently, you need to make all layers. First and foremost, unit testing on each of the layers should address it, but there is no such thing as comprehensive testing. So, "mocked UI" testing can put more tests which are closer to the real-life situation, but not limited to the set of test cases available with the "real" UI.
At the same time, all of the above might not be enough, because your "real" UI layer itself can have bugs. Automated testing with the "real" UI give you the chances to reveal them, too.
This way, all kinds of tests are not completely alternative to each other, they are rather complementary. I hope this example of logical reasoning can help you to evaluate testing scenarios to devise more effective test plans.
One final note: this is not alpha or beta testing, this is the testing performed as a part of development process. You should focus on those aspects of testing where you get the most benefits of this involvement: having all the knowledge on the system architecture, code design, even on particular skills or downsides of each individual developer, you can identify the most potentially problematic aspects and put more focus in on them in you test plans. Your question is related to only a small but essential part of this.