Behind the scenes, Drupal saves almost everything as a separate entity (each single paragraph, each menu item, etc.). This kind of abstraction (which is, by the way, also fitting the concept of relational databases perfectly) is very powerful because it enables you to define quite complex things (like a whole webpage) basically just by adding proper relationships to those separate parts which in turn point to other parts and so on. Those kind of intereconnections are called "entity references" in Drupal.
This concept, however, can sometimes be quite difficult to handle from a developer's point of view, because you have to be aware everytime a certain field's information resides in a separate entity. In this case, you'll have to follow the corresponding reference to get to its data. Sometimes, the usage of these references can be surprising. For example, the information about width and height for an image field is saved right with that item. But if you want to get to the URL or access the actual file, then you'll have to follow the reference, because Drupal will store the actual file that belongs to that image field as a separate entity.
With standard Drupal, you can follow those entities by using the virtual property "entity" explicitly (in this example we assume we have a node stored in the "mynode" variable):
{{ mynode.field_image.entity.url }}
This can be quite confusing, especially because - as explained above - some properties are stored with the field itself:
{{ mynode.field_image.width }}
If you dive down deep into a complex nested structure (e.g. like nested paragraphs), it happens quite often that you need to string one ".entity." property after another, just to follow through all the references that link those objects together.
DrupalX automatically dereferences all those references. It does so only if you are actually accessing them for performance reasons. The example above can now be simply written as:
{{ mynode.#image.url }}