N-Tier is not necessarily on different networks. Each tier is in a separate process, it could all be on one machine.
3 tier is somewhat out of fashion due to the out of process marshaling it requires.
Any extra tier, read: process boundary or worst communication across a network transport, is expensive.
In a 3-tier system the second tier is usually the business logic. A two tier system is most popular these days, since business logic is really difficult to divorce from user data.
A typical web application is two tier; user data and business logic are one tier and a DBMS is the other tier.
The biggest drawback is having to marshal/serialize everything multiple times as you bounce across tiers. The less tiers you have the less bouncing you need to do. All work you can do directly without jumping through hoops is massively more efficient. The difference between passing your data by (in-process memory) reference or through a transport is huge.
API code or a business logic in the form of application code is easily replicated and thus efficient to run in-process. A business logic tier offers little scaling opportunities since it depends on transactions against the data tier. You don't need tiers for reuse, you can reuse layers just fine.
I'd stick to layering for as long as possible. For what you call 'API' in your 'flow': look into application service layer pattern (which is a layer, not a tier) as an alternative.