Speaking as a former security consultant who regularly performed penetration tests of third-party mobile apps, it absolutely makes sense. In practice, mobile apps are a bit less amenable to black-box pentesting than some other types of app (such as web apps or kernel-mode drivers), but there's a lot you can do even black-box (and more with white-box, though reverse-engineering most Android apps is so easy they are practically always white-box).
A few common security issues we found:
- Apps not doing TLS validation correctly (for example, allowing self-signed certs or even arbitrary invalid certs).
- Apps that had vulnerable entry points (file associations, URI schemes, share contracts, or other ways to programmatically invoke them and then make them do something they shouldn't).
- Apps that used out-of-date libraries or SDKs with known vulnerabilities.
- Apps that used HTTP instead of HTTPS sometimes.
- Apps that used web views but didn't lock down their paths or JS execution, and were vulnerable to web app vulns and/or to phishing.
- Apps that stored secrets (credentials, tokens, private data, etc.) in plain text and/or in readable locations.
- Apps that stored keys or other secrets (for example, an API key for a web service) in their binaries, as though an attacker can't reverse engineer the app to find it.
- Apps that used native code insecurely, and had memory corruption bugs.
- Apps that used cryptography incorrectly and therefore insecurely.
There are plenty more that can crop up, though those are some of the most common and/or severe. Mobile apps are definitely capable of having security bugs, and should be subjected to security reviews including penetration testing.