Storing and using data are a critical part of any (web) application. Without somehow persisting data we wouldn't be able to build much of anything. However, different uses of data warrant different systems for storing and manipulating it. For the purposes of this chapter, I will use the word data to mean almost anything that has to be persisted somewhere, for any given period of time.
If you've done development in Drupal 7, you already know a few ways of storing data. We had entities (primarily the Node entity type, but others could be defined as well); the variables table, which was a relatively simple key/value store; and an API to interact with the database and do whatever we fancied. This caused many problems, such as a lack of consistency between APIs and much too heavy a reliance on the database for configuration storage.
In Drupal 8, various layered APIs have been introduced to tackle common use cases for data storage. The strength of these new systems is mirrored in the fact that we rarely, if ever, need to even use the mother of all storage APIs, the database API. This is because everything has been abstracted into different layers that help us handle most of what we need. So, creating a custom table is most likely not something you should be doing for storing your data anymore, although it definitely was a common practice in Drupal 7.