If you prompt the user to newly enter a Username and Password every single time the application needs to make an API call, they're gonna have a bad time and stop using it. Especially if a situation arises where a single "action" from their perspective kicks off multiple API calls that would need authentication separately. That's just not workable. That isn't the only way that "
The alternative is having the user's Username and Password stored on their device so the application doesn't need to prompt in order to send the request. The user can't tell the difference between the application holding an arbitrary token that enables access compared to username + password that enables access, so that's good. Unfortunately, there are some flaws in that as well, and those flaws are more security-relevant.
First, unless your application does internal encryption the username and password end up effectively stored right next to each other in plaintext. Even if there is encryption, the encryption key pretty much has to be stored close to what it's encrypting which isn't really much better. I can't say with precision how much of a vulnerability this is, and a token is likely to be just as vulnerable, but an attacker getting hold of a single token is likely less damaging than one getting the full username + password.
Second is, as you are aware, tokens are expected to expire with relatively high frequency compared to usernames and passwords. From the way your question is worded, you seem to be considering username + password in every request as the "highest level" of tokens expiring quickly, but it's actually the opposite: with no token in between, username and password become the token and only expire when changed. That makes the application somewhat more vulnerable to replay attacks, and makes it much more inconvenient to the user if you ever implement controls to detect malicious behavior: with a token, you can expire the token immediately but a real user can provide username and password to get a new one while an attacker who obtained just the token is blocked. A user entering their credentials every now and then is pretty minor, but forcing random password resets is significantly more burdensome on and it leans a lot on a secure password reset function.
Last, the username and password would be transmitted a lot more frequently. Ideally the secure connection is perfect and that's not a problem, but in practice there are some vulnerabilities that are more likely to be exploitable. For example, the CRIME vulnerability exploited the size of messages sent to leak pieces of information but required a constant value exist across many messages. That exact vulnerability is probably patched, but similar ones could exist in the future and if your requests are a little leaky then always having the username and password in them lets an attack piece-together that information over a long time, compared to a token which is less impactful to leak as well as limiting the time that an attacker has to obtain it.
All of that might not add up to a large security compromise, but I wouldn't risk it.