CKEditor 5 implements a custom data model. In order to load data to this model you need to have view -> model converters for each piece of the content that you want your editor to support. Then, you need model -> view converters in order to make this content editable (it needs to be rendered in the editor for editing). Finally, you need to configure the schema and sometimes customize certain features like Enter so they know the meaning of this content that you loaded into the editor and how to modify it. In other words, because of the data model a feature needs to implement the full life-cycle of a specific piece of content (tag, attribute, etc.) which it handles – from data loading, through rendering for editing, editing itself and data retrieval.
In your case, if what you edit are links but with a different markup, I'd recommend forking the @ckeditor/ckeditor5-link package. You can find there the mentioned converters. You can modify them to fit your use case and if you'll keep the rest of the code you'll have the whole UI and the rest of the logic.
As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.
This is how many developers perceive it and we are aware of that. But that's not true.
Let's state this clearly – CKEditor is not an HTML editor. It is a content editor and HTML is just one of the possible outputs.
Most of the use cases that you mentioned were related to manually adjusting the output and adding custom markup. Yes, this is possible in CKEditor 4. But CKEditor 4 is not meant to be used this way. When hacking the output you risk that the next time this content will be loaded into CKEditor 4 something will break.
Why? One of the reasons is that CKEditor 4 needs to understand the content. When content is being edited in the WYSIWY* mode the editor needs to apply many complex transformations to it. Those algorithm needs to make decisions based on the content that you're editing. So if you put into the editor content which it wouldn't generate itself, you risk that this content will not be understood and will be somehow broken.
This is, IMO, one of the most frequent reasons why developers dislike WYSIWY* editors – it's because they are abusing them.
So far I've been talking about CKEditor 4. How's CKEditor 5 different?
CKEditor 4 uses the DOM as a model. When loading data, the HTML is processed (read – filtered, normalized and escaped) but it ends up in the DOM anyway.
CKEditor 5 has a custom data model. When you load HTML into the editor, it's parsed and then features (initialized previously in the editor) try to pick up from this HTML the pieces they understand. This is called "conversion". As a result of a conversion, the content is being loaded into the custom data structure. The reverse process is executed when content needs to be rendered back to the DOM (either for editing or for data retrieval).
This means that if you don't have a feature which handles a certain HTML tag/attribute/style/whatever then the editor will automatically drop it.
This is how all modern rich-text editors work. Nothing special here (well, except the fact that we support OT ;P)
So, I think that the discussion above missed the point. Why doesn't source mode make sense for CKEditor 5? It's because you will lose all changes done in the source mode unless they are compatible with what the initialized features understand. But in this case, you'd be able to just apply these changes in the WYSIWYM mode.
Don't use CKEditor as a page builder (aka HTML editor). Use it exclusively for content editing. Write features for custom stuff that you want it to handle. Build a proper app for page building (if you need it) and use CKEditor as a part of it.
That's the direction which we were empowering in CKEditor 4 by the introduction of features such as Allowed Content Filter and widgets. And CKEditor 5 just made a couple of steps further.
It should be possible to implement a "wildcard" feature in CKEditor 5 (I guess we'd call it "AllowedContentTrue" ;P), but just... don't. Don't do it cause loading data is one thing, but then all the features still need to understand that content for editing.