Should I create fielded content types (with 1000+ tables) OR create custom entities with properties instead of fields (way less tables)?
It depends on your requirement. For example, if you want nodes to be revisioned then go for content types. If you do not want them to revisioned and just using them for storing content then I think entity would be a better option.

Update: 19th June 2016 Thanks to @jon-freed


  When it comes to performance-sensitive projects, nodes should really
  only be used for content, and we should separate as much as possible
  from nodes. Why? Nodes are revisioned, they fire a lot of hooks, and
  they have functionality that we likely won't need. Also if we know
  exactly what fields we should have in our entities, we can create our
  own custom entities to avoid all those joins of Field API tables.


As far as the choice between ECK and entity api module, it also depends on your requirement. Entity api module provides more control over an entity, for example if you want to create an entity controller for the entity then you should use entity api module. If you just want to create an entity and define some properties then go for ECK. ECK also allows you to created bundles for entities.

Also, you can easily create views for the entities, this site provides great example to work with entities.

Reference: Drupal 7 Entities: What are they, and what are they good for?

Update: (19th June 2016)

It is true that using fields will increase the number of tables, which means more JOINS during database queries. If the purpose is to store data only then you should go for properties. If you want to take advantage of Drupal fields (display the data in cool ways), then you should go for fields, but in this case you have to think about the performance.

We can add fields to nodes and custom entities. Therefore, using nodes will not affect performance. You can always alter properties of an entity using hook_entity_property_info_alter(&amp;$info)