You can limit number of simultaneously running builds in a build configuration on the General serttings page.

BTW it is useful to have several builds running simultaneously because it simplifies investigation of possible test failures - the lesser number changes in each build - the faster you can find the cause of the failure.

Let's look at this from the developer point of view. He checked in a fix and once TeamCity detected a change a build was started. Isn't it good for developer to see status of his changes immediately?

In your screenshot it seems build A did not have changes, while build B had. I do not know while build A was started (maybe it was triggered manually), but I definitely would not say that build B is a waste of processing time - it runs build with changes, and this build can behave differently. Note that usually TeamCity starts builds when changes are detected (if VCS trigger is enabled), moreover some of our users asked to implement feature to start builds so that each build run with one change only, becuase it greatly simplifies search for changes that lead to test failures.

Note that with help of trigger rules on VCS trigger page, you can disable triggering for some files. For example, if you have *.html files in your project and changes in them may not affect build status, you can disable triggering for changes with such files.

If you do not have enough agents and builds are slow, then indeed you may want to include as much changes in the build as possible.

By "change" I mean a single changelist detected by TeamCity (containing comment and a number of changed files). Some users want their builds to run with single change only. In this case it is obvious whom to blame if build fails.

In your case you can limit the number of simultaneously running builds. You can also specify quiet period for VCS trigger (http://confluence.jetbrains.net/display/TCD5/VCS+Triggers). In either way the effect should be similar - builds will run more rarely and will include more changes.