Entities were introduced into Drupal 7, they fundamentally change the way you can deal with things in Drupal and pave the way for some vast improvements in the use of Drupal as a development framework (rather than a CMS with customizable bits and modules that can be bolted on).
Entities are not proving easy for people to get into, although embraced by a number of contributed modules, many working Drupal developers don't fully understand or use them and although there are plenty of resources and explanations about them it is not easy to get started using them.
I believe that a key factor in the small number of developers embracing entities is that they are not directly exposed to site builders in Drupal 7, there is no sliding scale of entity use in core, you have to know about how they work and get your hands dirty.
Mastery of Entities may have been 'Take it or leave it' for a lot of developers building Drupal sites in Drupal 7 but I think for Drupal 8 they will be vital knowledge for anybody building medium to large Drupal sites.
Why should you care?This post by Adam Behnke makes a case that custom entities
"should be reserved for those who are expert Drupal programmers"I however believe that most Drupal developers will benefit from grasping the entity nettle before Drupal 8 becomes mainstream (even if that is just acquiring a background understanding) as there will be many fundamental changes introduced to the way we develop for Drupal 8 and taking it all in one big hit will be quite a shock (even though entities will evolve and change in Drupal 8).
Before Drupal 7Drupal 6 had nodes and the contributed CCK module, nodes may have been the cornerstone of Drupal development but they were targeted at a certain type of (content) data and there were a number of things in core Drupal that were not node-like enough to be treated as nodes (comments, users ....), each thing had it's own way of being treated in code.
Adding to the number of non-node like things in Drupal core, many custom modules introduced their own things, things that again had their own custom coding. Because all the things were different there was a proliferation of custom code required to integrate them with views, make references to them from other things etc. etc.
What the writers of all these core and non core things were attempting to do was model their data in a way that made sense for the problems they were trying to solve.
More fields pleaseOften developers simply wanted more fields that they could add to the non-node things. Giving rise to user profiles and similar.
Everything a nodeBecause many contrib. modules worked so well with nodes, there was a call and lots of effort to make everything a node. Modules that would convert comments to nodes for example and contrib. modules that defined their things as nodes even though that required some distortion and non-ideal design. Eventually this became cumbersome, it was not always good for performance, often made things confusing and led to questions like 'what about the comment settings on a comment node?'
Drupal 7It all started with the Field API, the CCK module was such a key part of Drupal development the benefits it offered had to be brought into Drupal core. The roots of the Entity API can be seen in this issue https://drupal.org/node/460320
because we all need a
"loadable thingy, that can optionally be fieldable"The issue and comments are worth reading.
A problem was simply that there was only time to put the absolute minimum required for the Entity API in Drupal 7 so the rest went into the contrib. Entity API module. This module is virtually a must for anybody working with their own custom entities and a requirement for many contrib. modules that use entities.