I am aware that block types that are related should have a matrix shared. For example, to implement a slider, there should be image and caption block types inside a slider matrix.
But what about unrelated block types? Do these unrelated block types need to have different matrix fields (from performance, UX, best practice point of view)?
I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.
It's not about performance or best practices, it's about your content structure. If you create one matrix field with two block types, both block types will be available everywhere that matrix field is used. So the question you have to ask is whether it makes sense to mix and match the different block types. On the other hand, if you use separate matrix fields, editors won't be able to have a mixture of both block types, even if you add both fields to a field layout.
Let's say you're working on a matrix field for the content of a blog entry. A blog entry consists of text, images, code examples, and statements. It makes sense two have those four block types in a single matrix field, since users need to be able to mix and match those block types in arbitrary arrangements and combine multiples of each blocks.
For example, to implement a slider, there should be image and caption block types inside a slider matrix.
Not really, unless I'm misunderstanding the example. A single carousel slide could have both an image and a caption, so you should create one block type slide with fields for the image and caption. You would only create different block types if you want to have different types of slides – for example, a slide with only an image or only some text content.
I remember i read in documentation something like reconsidering data structure when there are to many matrix fields which i can't find anymore.
There's a limit to how many matrix block types and fields are feasible, both from a technical and UX standpoint. If you notice you have too many block types and nested fields, it can make sense to use sections and entries instead. Instead of putting everything inside a single gigantic matrix field, separate out pieces of content as individual entries and use entries fields to relate them to each other.
Here's a good talk from Dot All 2022 on that approach:
