Gathering metrics (measurements) on a project is one of the more sophisticated project management processes and can be the hardest to implement. Because metrics can be hard to define and collect, they are usually ignored.
In my opinion, all projects should at least involve collecting basic information about estimated and actual duration. Next most important would be collecting information on estimated and actual project costs. However, it might (or might not) surprise you to know many organizations don't track project costs and don't really care about them. This is especially true in organizations where the project work is done using internal labor and there is no internal chargeback.
If your organization does care about costs, collecting estimated and actual costs for each project should be a requirement. For small projects, perhaps that's as far as you need to go. However as your project gets bigger it becomes more and more important to collect a broader set of metrics. These metrics are collected for two reasons.
You should always be looking for ways to improve your work processes. It's very difficult to do that if you're not gathering metrics. This is the classic cycle of measuring and improving, measuring and improving, measuring and improving, etc. Metrics are used to give some indication of what the beginning state is and whether you're getting better or worse. Examples of these types of metrics include the time required to complete an iterative development cycle, the effectiveness of team meetings, the percentage of deliverable reviews that are successful the first time, and how closely you are hitting interim milestones. Gathering these types of metrics is applicable only on medium and large projects because there is enough time to capture the data, analyze the results, and make appropriate changes. You usually don't have the time to measure and improve on short-duration projects.
It's important to know if your project was successful. If you have a short project, the measure of success may be as simple as the fact that your client did not complain. However, as your project gets larger, it can become increasingly difficult to tell whether you were successful or not, since some aspects of the project will be successful while some aspects won't be. For instance, you may have delivered everything the client requested, but you may have exceeded your budget and deadline. You need a more sophisticated approach that includes first defining a set of success criteria, and then collecting metrics at the end of the project to show whether you successfully met the criteria. These success metrics might include cost, schedule, client satisfaction, quality, defect rates, team performance, etc.
You should not collect metrics for metrics' sake. You should always have a reason — either to improve a process or to determine if you met your success criteria. Once you understand what you're trying to do, you can define and collect the appropriate types of metrics. Metrics are a lot of work, but also very powerful. Collecting metrics is the only way to quantitatively validate performance and success. Without metrics to back you up, you are just providing best guesses.