Fragment caching takes caching to the next level by allowing you to have a combination of dynamic and static content on the same page, which is extremely useful under heavy traffic because WordPress can easily make 100 queries to create a page, and if you have some “recent” something or statistics that change constantly due to high traffic, fragment caching will allow you to only run the couple of queries that update that stat (“most commented posts” for instance) instead of throwing another 100 queries at the server just because the stat changed.
The WP Widget Cache is actually an example of fragment caching, all those plugins become expensive very quickly, and fragment caching allows you to control the widgets so that they don’t need to be reprocessed just because something else changed on the page.
If you have a lot of traffic / activity, blog stats change all the time forcing to re-create the page and rendering caching ineffectual. For instance, if you are showing the most commented posts (with options to show day, 48 hours, week, month and year) with fragment caching you could set it so the daily stats show in real time and the others are cached recalculating only once at the end of the day. There is no point in calculating yearly stats on every hit.
Same for logged-in users, if you have a lot of traffic you could have a couple of thousand people logged in browsing the site and showing them dynamic pages will tax the server. With fragment caching you could point to the subset of the page that needs to be dynamic for the logged in users and serve the rest cached.
Since English is not my first language and my tech skills are very limited, perhaps you could read about Fragment caching on the Yii Framework for a more articulate explanation of fragment caching and granular controls like route, session, parameter, nesting (inside another fragment that is cached), etc.
