On Aliases
I’ll first speak on the software problem itself, so those that aren’t interested in the conversation of why one might want to use IDs in titles can skip my prolixity on the matter.
I think that this capability could be easily solved by the use of a more generic tool which could prove beneficial to anyone, not just those looking to very specifically use a string pattern prefixed to their titles as a link target elsewhere: that is the use of an alias or a handle by which an entry or document can be referred to in addition to its formal address, whether that be title, filename, URL or whatever.
This is really isn’t a new or novel capability, because we can think of the role of overriding a literal link target with visible text as being a form of ad hoc aliasing: [[Here is the Target|Here is the Alias]]. The desire to refer to a thing not by its formal address, but by a more contextually relevant or shorter handle is undeniable. We just do not often see that desire mapped into software level interlinking for some reason.
DEVONthink Pro, a database tool for the Mac, has this concept, where each document in the database can be given an alias, which as a string is then scanned for automatically in every other document. When encountered, the text becomes an active hyperlink automatically, and otherwise operates as a real link unless you change the text.
We also see this capability in MediaWiki, where I can refer to the octothorp symbol by an unusual name, and be redirected to what most people know it by.
There are several ways in which this could be implemented. In a GUI fashion, there could be some sort of button up near the title that displays a fly-out that you can view or provide an alias into. Perhaps the alias could even be displayed in the title area optionally, using a smaller font and some kind of grey “pill” formatting. Also along GUI lines, something in the sidebar or off the ellipses button might be better, as that might better allow for multiple aliases to be defined.
Another approach would be more aligned with the spirit of extended Markdown, and that would be to allow for some sort of pattern recognition in the content area itself. This would couple nicely with @icouto’s comment on the use of YAML preamble metadata, such as used in MultiMarkdown (this is the standard I use in all of my entries as well). For example:
Title: This populates the Obsidian note entry automatically
Date: 2020-11-15
Alias: alias-idea
And there you go, now you can verbosely refer to the document by its title, but alternatively you can just use [[alias-idea]] where brevity is valuable. Of course a ZK user could put their ID there, but one might use it for any variety of reasons. It could even be used to make external links less clunky and more long-term resilient, like obsidian://open?vault=something&alias=alias-idea.
Of course that is a bit more operationally clunky than a plugin that looks for a title pattern and just uses that as the alias—but perhaps that could be the plugin, and the alias itself be more of a core feature that the plugin automates—and such an approach would allow for a far greater variety of people to benefit.
On The Virtue of IDs
All right, on to theory. 
I don’t use Zettelkasten, rather a system of my own devising that is based more upon the theories of Noguchi, but it does bear a number of resemblances to the system as I understand it, in particular with regards to the use of an ID per note. While I can understand why most people out there would be perfectly fine working on text titles alone, I don’t think that alone is reason enough to suggest that the use of IDs for entries is obsolete or that it lacks any compelling merit, even in a purely digital environment where software augmentation is depended upon.
The page that you linked to had some good arguments for why you might want to use an ID, but they don’t seem to be addressed here, rather it was only used to illustrate that in general, it is advocated for. Here are some of the reasons given, along with my commentary on how I independently arrived to the same ideological point:
Pre-processing
Completely does away with the compatibility argument you raise. This is the approach I’ve taken since 2005 or so, where all of my bespoke syntax, including cross-referencing via IDs, has been handled seamlessly for so long that I forget it even happens. This can be an asset, rather than a work-around, which I’ll illustrate below.
Link resilience & flexibility
One of the first points raised in the linked article is that one should think very carefully before adopting any software’s hyperlinking system, and this is a point I strongly agree with. They make the point in the framework of resilience: you don’t lose the link if you have to leave the system (more true for non-markup users), but there are good arguments for extending the usefulness of links in ways most hyperlink systems completely ignore.
This is where post-processing can become an asset. One area where my approach differs from ZK is that my linking syntax is capable of (a) declaring intention and (b) annotation. While some link formats can do this (HTML clutter comes to mind), Markdown and Wiki style links typically do not. They at most allow you to change the visible text when the document is rendered, but that is not a very flexible tool for adding additional information to a link, and adds clutter while writing and editing.
Granularity
The notion that each entry is in itself a link target is only one small part of the idea. In fact in my earliest prototypes I did not ID each entry, but rather put all of the IDs into the content. This was because, at the time, I tended to write daily aggregate entries with multiple topics. Links, for how I worked back in '05, were purely point-to-point. When I changed my methods to add an ID to the entry title a couple of years later, it only gave me another link target to point at. The key thing here is that the link remains predictably succinct no matter the depth of the target.
Succinctness
Yes, something that I am not very good at. 
This concept leads to a digression on brevity and legibility in a prose context. Here is an example of what I mean by avoiding mechanical clutter; visualise these different examples embedded in the middle of a paragraph:
[See also](re20319867>)
Versus
[[This is the verbose name of a note#Here is the topic heading I want to point at|See Also]]
Or worse, the Markdown approach:
[See Also](This%20is%20the%20verbose%20name%20of%20a%20note#here-is-the-topic-heading-i-want-to-point-at)
The latter two require a fair amount of squinting—neither provides a very readable result in terms of being able to allow the eye to skip over the technical baggage and get to the “See also”, or the prose amidst the technological apparatus.
Where granularity comes back into the picture is that the inverse of my outbound link syntax looks like this: 20319867<. That, as a piece of text, can be inserted anywhere I want… like right there. If I were to put a link to that ID in another document then I would arrive at this paragraph. I don’t need a heading, or a figure caption, or any other typical ID generating element around it. So succinctness and granularity go hand in hand, when devising legible systems for networking data.
In my interpretation, this is what the author of the article is getting at when they ask, “Think outside of the box for a moment: when note identity and file system representation are decoupled like this, how could we use information identity elsewhere?”.
With a system that does not depend upon formal titles or interior structural elements in order to create a link, we do not need to even think in such terms while building our network of ideas. We have freedom to embed networking as deeply or as broadly as we like.
Inherent Double-Endedness
A cross-ref syntax where the outbound link is essentially identical to the inbound anchor makes for a naturally double-ended system. Consider the previous example, where I link to the paragraph above from another document, and instead of using that data as a cross-reference, I plug it into a search tool. The result gives me both documents, and indeed any other places in the network where I chose to refer to that spot. It doesn’t require any alteration to what I do to get that ability. The Wiki or Markdown link approach, on the other hand, creates a link that looks nothing like the target (and may well be cluttered by encoding and other apparatus to make the link HTML-valid). You have to select individual components out from it and perhaps even use multiple searches to get to the spot you really wanted to get to.
Now you might say, that’s just what back-links in a tool like Obsidian do for you, and you’d be right, so long as we constrain ourselves to the use of software that has that capability (rare). The key point here is you get this capability using ID-based links with nothing more than ls and grep on the command line. Pretty much any software that is capable of storing entries and searching their contents is thus a fully capable back-referencing system thanks to the data being organised for that approach.
And if that clicks, perhaps it better clarifies the concept of portability, as being something that goes beyond whether you use strict Markdown syntax or not. If I can lift twenty years of archived data, millions of words at this point, and dump it into a completely new piece of software in a lossless fashion, with 100% capability without really learning much of anything about it… that is portability.
Accessibility
Closely related to this concept is how easy it is to extract what amounts to a link from any source material. If it is easy to double-click or select the important part of the text out of a link and use that to paste into another program, then our links remain functional across contexts. We wouldn’t expect our coding editor to understand a cross-reference to a document in our archive, so being able to easily extract the target no matter its specificity increases its usefulness. It also means we don’t have to depend upon software to provide an external link feature, though such is always nice, having data that doesn’t need it is nicer.
Avoiding Constraints
In Writing Methods
@icouto: The point about portability, however, is arguable. Even if we’re planning on manually managing our text files, we’ll be likely using a markdown-compatible editor. Therefore, the closer we adhere to the standard markdown syntax, the more portable our notes will be.
So then we have added a constraint to the archive, that it must be comprised of Markdown files. You will seldom find a more outspoken advocate of Markdown, but my system straddles all manner of file types. I use org-mode, YAML, .taskpaper and other various plain-text formats for information management. My system extends into code itself, embedded in comments pointing back to tickets and to do list entries. It even extends into the realm of paper, for my system was based off of how I was already marking dates down in handwritten journals.
With my ID system I can refer to an entry right here in this forum, with a compact link code like xr05273912> that would enable me to, within no more than five minutes, stand up and pull a book off of my shelf and be reading the desired entry from a journal, penned in early Autumn of 2005. I can do that because my ID is a date, and that gives me everything I need to know to pluck the right thing off the shelf and flip through pages until I reach the right spot. If all I had was a title, there would not even be a point in bothering to try and find it, it would take months!
While not everyone might need such a capability or that degree of specificity, the fact that I can do that again means my ability to find data outside of “The Archive”, across my computer, across old backups, FTP servers and so forth and diverse file formats, remains unhampered.
A title all by itself is never going to provide that level of inter-connectivity across a broad spectrum knowledge network.
I came up with my bespoke link syntax before lightweight markup hit the scene, but when it became a thing, my system slotted right into it without any hassles—portability. If I want to refer to something in such a way that it has a clickable hyperlink in prose, then [this is all I need to do](re20319744>). It’s perfectly Markdown compatible, as you put. You might argue it doesn’t work, but it does if you have built a system around that approach already. For me when a Markdown file gets typeset or output, my link gets turned into a valid file:// URI prior to getting to the Markdown processor. That can be useful with Markdown, but also becomes useful in Org, or whatever.
In Software
Now, if your filename is different to your note title, you could still end up with 2 notes that have the same title (but different filenames). But a clever app like Obsidian makes it very easy for you to avoid that: just look at your ‘backlinks’ and ‘unlinked mentions’, and you will see the other note staring back at you.
This is another constraint, but now we aren’t merely constrained by the methodology with which we type in data, but by the software we use. Now our archive is hampered if you take it out of Obsidian, or any program that can shore up its weaknesses.
The original argument you made was that the digital age itself has made the ID obsolete (which I take to be a purely humanist statement, obviously IDs are bread and butter in the digital realm), but unless the digital age is all about getting your work stuck in one program because it falls apart outside of it, then I guess that’s just not what I’m about. It’s certainly not what I designed my system for—mine was rather designed out of a frustration with how data becomes constrained and limited by the software we put it into. I wanted data to become liberated from software design, to remain fully functional no matter where you put it, even as loose files, even as a stack of printed documents.
The Freedom to be Lazy
One of the arguments of the proponents of using an ID in the note title, is that it ensures ‘uniqueness’ - that is, it ensures that no 2 notes will have the same title. In a Zettelkasten, however, all your notes should be kept in one big folder - i.e., there should be no hierarchy of sub-folders separating the notes. In most computer systems, this means that if you try to create 2 files with the same name, you’ll get a warning anyway.
I think in stating it that way you are dwelling on the technical aspect more than the human aspect. Sure, the OS won’t let you have two files named “The importance of IDs in names.md” the same folder, so if I were to immortalise this conversation as a sequence of separate entries, I would then have to contrive some serialisation technique to handle that problem. Or I would have to creatively label your post for you in my system, and my posts, and at what point does that necessity hamper the more useful attribute of the title here: as a binding agent in a list that declares these entries as being related to a chain of conversation? If each entry has a seemingly unrelated title it depends upon other agents for that binding (it does, to be clear, but we should have a human-friendly front end to that).
So in my system, I have this:
20182056 m2.1.Obsidian The importance of IDs in names
20319752 M2.4.Obsidian The importance of IDs in names
20319852 M2.1.Obsidian The importance of IDs in names
Here we have, in order, your post IDed by when it was posted, a first draft response and the one you are actually reading right now.
Do I need more for the title than how I think of the conversation thread? Not really! I could put your name into the title, but I don’t really need it because the lowercase ‘m’ already signifies to me that I didn’t write that particular entry. Could I put ‘draft’ into the second title? Again, sure, but I don’t need to because I know in my system the minor number ‘4’ indicates an unfinished work, which in the context of ‘M’ (communication that I wrote), ‘2’ (publicly) tells me it’s a rough draft for a post to the Obsidian forum (‘1’).
So when you’ve got chronological/identifier and taxonomy information already in the title, you don’t really have to be as creative or force variation into your titling to please the gods of the file system (or your ability to link properly).
This archived conversation example is only one case where using the same title for multiple different notes is simply more convenient and even to a degree more informative, than having to come up with verbosely unique titles.
IMHO, the use of IDs in note titles - whether based on time stamps, UUIDs or any other arbitrary notation - is an antiquated an unnecessary procedure, left over from the days of building Zettelkästen with paper index cards.
Again I think that is a limited way of looking at it, since in my case I knew nothing of ZK until fairly recently, but yet I came up with a very similar approach independently, and specifically to circumvent weaknesses in digital information management. It wasn’t that I had been using IDs in paper journals all along and just kept doing that when I started digitising, but rather the other way around. Perhaps I’m being a bit pedantic on this point, however, but it seems to me the crux of your argument is that it is a vestigial tool without digital merit, or that perhaps software should circumvent the need for data that can fully represent systemic qualities on merit of its content alone.