What is the benefit to creating new entity types over just building a new content type?
It seems a bit overkill to do all of the custom coding that is required to create a new entity when you have all of the CRUD and Views functionality already built into content types.
It's not so much about what the benefits are but more about what's appropriate for a particular situation like you've said. You can represent pretty much anything with a node and for 99% of situations (as I've found at least) you won't need to implement custom entity types.
I always think of the taxonomy_term entity type as a good example of why not everything should be a node/content type:
A taxonomy term is essentially for grouping together different entities and as such doesn't require the same functionality as a node. While you could theoretically use a content type to perform this functionality (with perhaps a node reference field), a taxonomy term doesn't need to do the same thing as a node so it doesn't really make sense to do so. The same can be said for the user and taxonomy_vocabulary entity types.
So a taxonomy term is created as a separate entity and is programmed to do only what it needs to, while still getting the benefits of being able to have fields attached, etc.
I think the simple answer is that when a node/content type doesn't do what you need it to, or it's just a massive amount of overkill/overhead for very little benefit, then you should choose to write a custom entity.
This is only based on my personal experience; I'd be interested to hear what someone directly involved with Drupal core development had to say about this.
A very simple rule of thumb I use is whether your content need to be publicly displayed on its own. If so, then go for node, if not choose an entity. Entityforms now allows you to create an interface to fill out your entities.
For example, on a website made with D6 we build an advertisement content type (with its image field, begin/end display date...), but then you have to make it not published by default and give your editors the rights to edit/view these node and hoped no views/search will display these on the outside world. It's quite cumbersome and it would be easier to deal with entities.
An entity represents a specific use case.
I believe the credit for this simple definition goes to Fago, but I'm to lazy to find a reference.
We could use Content (aka Nodes) for all use-cases if we wanted to, but often that doesn't make sense.
Content has an author and settings for both comments and menu location.
Users, represent a use case different enough from Content because on a user neither of the above makes any sense, while on the other hand, a user must have an e-mail and a password.
Taxonomy terms stand out because they have the built in functionality to be arranged in a hierarchy, even a circular one.
If your use-case is similar enough to an existing entity, go with using that entity. If your entity is governed by significantly different rules than any existing ones though, create a new one.
There is also An Introduction to Entities, but unfortunately it doesn't really answer your question.
I think it is all about the context, a node is largely used for content so that would be blogs, articles, faq's etc. While user for profiles like staff, customers etc. Example of when you might create a new enitity:
While you could use a node for something like a support ticket it might not be the best template and defaults... Hope that helps.
This is subject to discussion and in the end you have to make your decisions as a developer.
I choose entities over nodes whenever the data should not be publicly available with their own url. Nodes are getting by default a url alias, published status, a title, meta tags, ... while entities just get a record in the database.
"I want to be able to add as much banners with text as possible and then in a blogpost choose between one of them"
Entities can be created with less overhead than nodes since they don't need to have all the heavy-duty functionalities that entities have.
It also means storage can be simpler - you can build them to grab all the information in a simple query without JOINS if you want. All the fields nicely in just one tidy table.
This can be a huge benefit if you have a lot of functions that need to do queries on the entities, and you are updating lots of entities simultaneously with UPDATE queries to the database. If you can make sure the data is relatively self-contained in a single table, you have fewer worries and possibilities of data corruption.
A content type is designed to be site content. That is, each content type is designed to be publish and appear on the site. For example, an article (out of the box) is designed to appear on the first page.
Now, let's say you want to create an something like an employment or apartment application form. Obviously, you would not want to publish someone's employment application on your web site. Also, what if you wanted to build a list of customer / lead contacts? Would you want to take a chance that this information might be published by mistake on your web site? Personally, I would not.
Hence, the entity form module that is discussed above. It allow you to create a entity type that is not designed to be content. However, these entity types are available to any module that supports entities such as rules, views, and organic group to name just a few.
And then you get into Drupal Commerce where the products are entity types. Basically entities enable developers to extend Drupal in way never foreseen by the original Drupal designers.
