I'm guessing that you mean layered (logical units of separation) rather than tiered (physical units of separation/deployment). An example of a tiered system would be a web server (1 tier) delivering web pages (another tier) which draws on data from a database the 3rd tier).
The usual aim of a layered architecture is to separate out responsibilities. This has two key benefits (amongst others).
First of all your design will be clearer as responsibilities won't be muddied and thus the code will be easier to read, understand and maintain.
Secondly the chances are you'll be reducing duplication - for example in a web app if your pages are also handling business logic (or horror of horrors data access) as well as displaying the pages then you can be fairly sure that multiple pages will be trying to do the same or similar things.
You don't need to architect (e.g. into layers, although there are other ways) any piece of software but for anything apart from trivial things the result will be an unmaintainable mess if you don't.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…