In the beginning there was the big ball of mud. The application was without architectural structure. Then Trygve Reenskaug said let there be Model View Controller. And he saw that having three modules focused on their respective responsibilities was good.
Others saw that this idea was good so they changed the names, the context, and claimed it was theirs. Thus was 3 layer / n tier architecture born. Logical separation granted the potential for physical separation. And they saw that it was good.
Others saw that layers were separations drawn horizontally and decided the next step was to draw some separations vertically. This time, separations were not between concerns, but between uses. Thus micro services were born. To promote micro services a name was needed for things made in the before time. Thus the name monolith was born.
Relationship between monolithic architecture and n-tier
Monolithic is what a microservice advocate calls your n-tier application when they want you to feel out dated.
Since n-tier architecture divides the application into logical layers (usually Presentation Layer, Business Logic Layer, Data Access layer) and physical tiers, based on how many tiers are involved, can we talk about 1-tier, 2-tier or 3-tier monoliths?
Yes.
Is a desktop application that runs only locally a 1-tier since the 3 logical layers (UI, Business Logic and Data Access Layer) run on a single machine?
A logical separation does not require physical separation. It simply enables it. Tiers, layers, and modules are logical separations. Even micro services are made of logical separations before physical ones.
For example MS Excel?
Maybe. I'd have to look at the code.
The difference between a 2-tier and 3-tier monolith would have as its only difference the fact that in the 2-tier the Business Logic and Database layer are executed on the same machine, while in the 3-tier the database is executed on a separate machine?
Again, physical separation is secondary to logical separation. Without logical separation physical separation simply doesn't work. I'm happy counting the logical separations. A big reason why is because that tells me how many physical separations are possible with this code base.
But if you insist on talking about a particular deployment, well yes, you can count the physical tiers. If you count more than 1 then without changing code I can redeploy it with fewer physical tiers (ain't virtualization fun?).
Don't get too hung up on what the tiers do. That isn't standardized. Some don't even use a database for their persistence.
When we talk about monolithic web application nowadays, do we usually refer to a 3-tier or 2-tier monolith?
I talked about that before.
When I see this:
Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)
I think of it as 3-tier. But that might just be me. I'd still call it 3-tier even if all three ran on the same box. It's about logical separation.
Also when we talk about logical separation, ok that means that there are different components that take care of each of the respective 3 aspects (3 layers), but does this coincide with a separation at file level (for example controllers defined in a folder, views under another etc...)?
It sounds like you're asking about package by layer. I've talked about that before. I prefer package by feature.
If the code has HTML, CSS, JavaScript, and server-side logic (like C#) all mixed together in the same file or component, can we still talk about a proper logical separation into layers?
You can talk about it. But done like that it doesn't sound like you're achieving it.