SharePoint Pages from a developer point of view

From a developer point of view there are three main kind of pages in SharePoint: Application Pages, Master Pages and Site Pages

Application Pages

Application pages are pages stored in a folder below {SharePointRoot}\Template\Layouts they are accessed through a Virtual directory _layouts which is present below all SharePoint sites. The behave as completely ordinary ASP.NET pages except that they know which SharePoint site they are accessed as part of. They should be/are used for things which should be available on all sites like different kind of settings.

Master Pages

Master pages are just ordinary ASP.NET master pages which can be used to control the part of the html which is common to all pages in a Site Collection, like overall layout and navigation. The contain ContentPlaceHolders which is then replaced by the content of Content controls on the individual pages.

Site Pages

Site Pages are a very special kind of pages. They are (at least initially) usually stored in the folder for the corresponding Feature/Site Definition. They become available through a <Module> element in a Feature/Site Defintion or though code like "add page", which when the feature is activated (or the Site Definition provisioned)(or the code runs) will create a record in the content database for the site linking a URL to the file in the file system.
At this point the site page is uncustomized (or Ghosted (old terminology)). But using SharePoint Designer, the object model or browser the end user may change the content of the page for a specific URL (in a specific site). The changed page is then stored in the content database and is now customized (or Unghosted) and has some limitations due to security (can't contain server side code in markup, may only inherit from safe base classes and may only contain controls which are safe).

Site Pages are the pages you'll normally let the end users use. They come in a number of variations:

Pure site pages

(My own term) Standard ASP.NET pages where the developer controls what's on the page. Very uncommon.

Web Part pages

Pages inheriting from Microsoft.SharePoint.WebPartPages.WebPartPage containing a number of WebPartZones where the developer/end user can add web parts to control what the page shows/can do. In previous versions of SharePoint very common and very powerful.

Wiki pages

The new way of creating content pages. Very similar to web part pages, but instead of having multiple web part zones it usually only have one which is hidden. It then has a Wiki field which can easily be edited and can contain markup which will make the web parts from the hidden zone appear inline in the content (as divs)

It can be combined with multiple WebPartZones to allow more control of placement of web parts.

Publishing Pages/Page layouts

From a developer point of view publishing pages isn't really pages, but listitems which is bound to a Page Layout. The Page layout on the other hand is almost what I call pure site pages, but can only be displayed by a corresponding publishing page listitem, they contain controls which allows display/editing of the columns in the listitem.

SharePoint Pages from a end user point of view

Settings pages = Application pages

Pages where they can change some settings, but have no control of what's on the page

Web Part pages

The standard type of page in a site which started as a blank site. Allows the end user to put web parts in different zone, which makes them ideal for building "mashup" application, but hard to create ordinary content in.

Wiki pages

The standard type of pages in collaboration sites. Allows very easy editing of content and the mix-in of web parts when needed. Very good for unstructured content.

Publishing pages

The standard type of pages in publishing sites. The structure of the content is very much controlled by the page layouts, usually very limited use of web parts. Very good for making the site look consistent.