"Take the following code, which might be found in many modules and themes in the Drupal 8/9 world.

/**
 * Implements hook_preprocess_node().
 */
function mytheme_preprocess_node(&$variables) {
  /* @var $node \Drupal\node\NodeInterface */
  $node = $variables['node'];
  if ($node->getType() == 'article') {
    $variables['colour'] = $node->get('field_article_colour')->getValue()[0];
  }
}

In the code above we are using the hook_preprocess_node() hook to intercept the rendering of a node. We then use the bundle name to find out the type of node being passed to the hook before getting a value of a field from that node and setting it to a variable in the template.

Whilst this code works, it tends to be quite fragile. Writing if statements like this to catch which type of node has been passed is fine, but with fields used by more than one content type (e.g. the body field) this simple check soon becomes a bit tricky to manage. It's easy to add more conditions to the if statement until you end up with a complex function peppered with conditions. It's not uncommon to come across preprocess hooks that are hundreds of lines long (which is bad practice if you can't tell).

Grabbing values from fields to pass to the template like this is ok (there are better ways to do this even without bundle classes) but in practice, this can become a weak point in your code. In recent years I have swapped to using the hasField() method of the entity to check to see if the field exists before using it, rather than any direct comparisons with the bundle type. This allows slightly more robust code that can be adapted to other content types without any code changes.

There is another issue here in the form of a lack of encapsulation around hooks that change the way in which entities operate in a Drupal site. What I mean by this is that there is nothing to stop multiple themes or modules from implementing the same hook and changing the template in some way. The problem is deeper than this as there are lots of hooks that change the way in which entities operate, and they don't have to be collected together in the same place.

As an example of another hook, it is possible to add a hook_entity_access() hook to allow (or disallow) access to entities in certain operations. The following code will return an access denied page if a user who does not have access to the site administration pages attempts to view it as an article content type.

/**
 * Implements hook_entity_access().
 */
function mymodule_entity_access(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Session\AccountInterface $account)
{
  if ($operation == 'view' && $entity->bundle() == 'article') {
    return AccessResult::forbiddenIf(!$account->hasPermission('access administration pages'));
  }
  return AccessResult::neutral();
}

My point here is that this hook can be placed in a different module than the preprocess hook above. This means that although both hooks interact with the same entity, they are in different parts of the codebase. It's common for preprocess hooks to be placed in the theme, but it depends on the style of the developer making the function. Different hooks can be placed in different modules and themes throughout a Drupal site.

This "action at a distance" anti-pattern is quite prevalent in Drupal, just due to the way in which hooks work. You might find that different modules will implement different sets of hooks that can often work against each other. Turning off modules can also have unpredictable results if it disables a certain hook that your entity was reliant upon.

This is why it's really important to employ behavioral testing on a Drupal site as there can be a disconnect between what you test using Drupal's testing frameworks and what actually happens on the site.

Entity bundle classes attempt to solve some of these problems by moving the "hook-able" functionality an entity might need into a single class. Or at the very least, a hierarchy of classes.”