You can use blocks in two different contexts, to achieve different results:
Using Structured Text fields, you can produce great pieces of content by interleaving free-form text with blocks representing predefined graphic components (CTA, quotes, image galleries, infographics, etc).
Using Modular Content fields, you can create a page-builder to let your editors combine different blocks together like Lego pieces to build any kind of dynamic layout (especially useful for landing-pages).
Just like records, a block is a composition of fields, on which you can define custom validations;
Blocks defined in the library can be reused across different models;
Unlike records, blocks do not live an independent life, but exist only within a parent record. For this reason, blocks do not count towards your plan records limit, and cannot be referenced in Link fields. They only live inside Modular Content and Structured Text.
When a record gets deleted, all the blocks it embeds are deleted with it. This leaves no orphan data structures laying around your project.
Block fields per se cannot be localized. It's the containing Modular Content or Structured Text field that can be localized, so that different content/blocks can be defined for each language.
It's fairly easy to recognize when a piece of content should be modeled as a model or block if you ask yourself the following questions:
"Would I ever want to reference this content outside of the record in which it is defined?" — if so, then it is a model.
"Does this content have dignity of its own, or does it just make sense in the context of a parent record?" — in the first case it is a model, otherwise it is a block.
"If the parent record were to be deleted, do I want this content to be deleted as well, or would I like it to remain?" — in the first case it is a block, otherwise it is a model.