HTML5 gives developers new powers, but also makes old tasks easier. Much debate among the standards-makers tries to define the fine line between 'convenient' and 'too particular', and 'a large set of reasonable use-cases' now functions as WHATWG's most important single criterion of feature acceptability (as the debate over the <time> element spotlighted, a bit starkly).
The progress element represents the completion progress of a task. The progress is either indeterminate, indicating that progress is being made but that it is not clear how much more work remains to be done before the task is complete (e.g. because the task is waiting for a remote host to respond), or the progress is a number in the range zero to a maximum, giving the fraction of work that has so far been completed.
The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.
Both of these could be developed fairly easily using HTML4 tech, with some simple math (I remember building these in VB) -- but because they address so many different kinds of user experience (i.e., they have so many different use-cases), they proved useful enough to receive entrance into the standard.
Both elements are heavily customizable, however, and especially if they appear frequently on your site, may need to be styled appropriately.
- The <progress> element exhibits slightly more complex default behavior, depending on the browser-OS combination, so a heavily-exemplified discussion like 'Cross Browser HTML5 Progress Bars In Depth' should help a good deal. None of the code is difficult, and the results can serve many purposes -- so your ROI should be pretty high. Also includes links to recommended polyfills.
- The behavior of the <meter> element is less intrinsically complex, but its uses are varied enough that strong familiarity will be important. html5doctor's 'Measure up with the meter tag' includes much less styling detail than the <progress> guide, but the focus remains where it probably should be, on marking up the metered data itself.
Update: for more pre-formatted CSS3 progress bars, see also this project on github.