Why didn't we got rid of primary entity keys in favour of UUIDs? I just remembered, while working with custom entities, that Drupal 8 was supposed to bring UUID support and replace the old "entity id" keys but then I've also noticed that the old fashioned entity id key is required by tye EntityType annotation and interestingly the UUID key is just optional.

Is this so that urls/entites are easier to remember by their "nid"?

And most importantly: should we use UUIDs or entity ids in logic and/or database operations?

Is this the final approach or we'll see entity id disappear in beta/rc/stable release?

Personally I don't see any good reason to keep using the typical serial keys when we have UUIDs now.
For context and some related discussions, see #1726734 Replace serial entity IDs with UUIDs in URLs, or even globally?. There is also a related issue about using UUID's for references, which I can't find right now.

So one argument is that all URL's would then become very long, there's no user/1 anymore but user/LONG-UUID.

Another is the database performance, the primary key is the main index of every table, and making that bigger makes every change to that table more expensive. Yes, so does having 4 tables, but there's still the hope that to make that optional for non-multilingual sites. I doubt it will be possible, but we will see.

And you have to keep in mind that the storage would not only be increased by the actual field, but also every reference, so every single field table entry would then have to store the full UUID instead of the considerable shorter primary key.

And related to the issue that I can't find right now is that it would also slow down joins that involve entity tables.

That doesn't mean that it will never happen, but it has been pushed back to 9.x to be re-evaluated there.