A content type is essentially a template for content. Out of the box, SharePoint provides many content types including Item, Document, Announcement, Issue, Task, and many more. You can, and should, create your own custom content types for your own content.
Creating lists and libraries without thinking through the content structure can lead to a big mess. Imagine you have hundreds of project sites. Each project site contains a document library for Project Deliverables, another for Project Support Documents, and yet another for Project Admin documents. You can simply create a library, add some metadata, and then save the site as a template. If you need to make updates to those libraries, for example creating a new metadata column, or adding a workflow, you will then have to manually make the same updates to every library across all of the project sites. If you have 100 project sites with 3 libraries each, that's 300 updates! What if you want to find all of the Project Deliverables across all projects using search. You would have to configure search to target each library by path or by name. You have no simple way to simply say "search all of the Project Deliverables across all projects".
Now take a step back and create a separate Content Type for each of the libraries. You then configure the libraries to use that Content Type. Now when you create 100 project sites, you can simply update the Content Type in one place and all of your updates automatically get pushed down throughout all 100 project sites. In addition, you can now easily configure search to return all documents for a particular Content Type.
This type of planning can apply to more than just Project Sites. If you are creating a new list or library in SharePoint you should consider these things:
What type of content will be stored here?
Will we ever need to use this type of content elsewhere, perhaps in another team site or project site?
Will we ever need to apply a workflow to this type of content?
Will we ever need to apply document retention to this type of content?
If you answered yes to any of these questions, you should use a site Content Type. In fact, to make things easier, you should consider always creating a site Content Type just to make things easier to maintain and more consistent going forward.
In addition to Content Types, Site Columns are another component that should be looked at very closely. Every Content Type is made up of one or more Site Columns.
Consider the site column purpose. Where could this site column be used?
Does this site column already exist? Perhaps somebody else has already created a column for this purpose.
Do the values in this site column apply only to my content or to the entire organization? A common example of this is a selection of locations, departments, project status, etc. These are list of values that should be consistent across the organization. You want to avoid duplicating this list of values across multiple locations in your SharePoint environment. Instead, create a Site Column at the global level so everyone can utilize the same values.
Getting everybody on board
All of this is easier said than done if you have opened up control of your SharePoint content to business users. You'll need to make sure these site owners understand the purpose and benefits of content types and site columns.
Training - Show the content owners the benefits of content planning.
Guidance - Lead by example. Use content types yourself and encourage others to use them as well.
Here is a quick story about an experience I had with a past client. We were building a knowledge management system that would contain thousands of documents. When we defined the requirements for the project, the client insisted that they would not use any additional columns other than the name, title, and keywords. When implementing the project we decided to create a custom content type called Knowledge Base Document that inherits from the default Document content type and had no additional changes. After being in production for about six months, we needed to add a new column to every library in the application. There were hundreds of libraries and thousands of documents. However, all we needed to do was update the Knowledge Base Document content type by adding our new column. All of the document libraries inherited this change immediately and we were good to go. This is a real life example of how using a content type can be real time saver.