I'm leaning towards less abstract and more practical explanation that answers the question: "How and why do I want to split my system into tiers and where do I place them on the servers?"
Essentially, when you create a simple website that uses a database, you already have 3-tiers "out of the box":
data tier - the database. But if you are using a short-lived memory cache or file system then we might argue if that can be considered a "tier" or not.
application tier - the code that executes on your server(s).
presentation (or client) tier - the code that executes on the client's machine and presents the results to the client
Now, how do we get the 4th tier?
Most probably, there is no need to split the client tier. It's on the client's device and we want to keep it as simple and efficient as possible.
Could we split the data tier? I have seen some systems with APIs around databases, Azure blobs, file systems etc. to create some subsystem that could be considered a tier. But is that still the same data tier (a.k.a fundamental services tier) or can we consider it a separate entity? And if we separate it out, will it be on the same physical (or virtual) server as our database, so we can protect the data from direct access?
However, in most cases, it's the application layer that gets split.
One part is still named application tier. It becomes an internal API web application and lives in secured zone where it can access the database. Nobody can access the database directly, but only through this application layer.
The other part becomes a consumer of the application tier APIs through some kind of a connection (HTTP client etc.). The consumer might be called presentation tier (confusing - wasn't it the same as client tier?), even if it itself has only JSON APIs and no any user-friendly formats.
But then the question arises: in which cases we, developers, might want to complicate our lives and split our web application into presentation tier and application tier, instead of keeping them as layers inside the same web application?
At serious workloads, a separate application tier might be good for scalability or it might be a requirement of security to deny database connectivity to the web server that is exposed to users (even the intranet ones).
I have seen some ambitious projects going for 4-tier from the start and then cursing themselves for overengineering things. You have to keep track of those internal connections, security, authentication tokens, keeping sockets under control (not opening a new HTTP connection on every request), avoiding accidental sharing of data of multiple parallel requests through carelessly created global HTTP client instance etc.
