See the message in the linked commit from 2019. To flesh it out a bit:
Say a user clicks on “view in disposable” for a file or a link.
They’ve taken care to set up the disposable template used for this (and hence the disposable instantiated from it) to have some sort of more isolated perspective: Maybe it is connected to a proxy. Or maybe it has a different software selection, because they don’t want the potential malware handled by the disposable to have any insight into what software they normally use.
Malware in the disposable can launch another disposable from within. If Qubes OS used the global default disposable template for that one, it would be an easy breakout from the intended isolation. The user would have to avoid this by never forgetting to explicitly configure the isolated disposable template to use itself for launching new disposables. Which is quite easy to forget though. Or more likely, to not even consider the finer points of default_dispvm property inheritance (from disposable template to disposable) and its relation to global default fallbacks, until it’s too late. Qubes OS makes a trade-off that avoids this footgun and defaults to a safer setup, at the cost of now requiring annoying configuration (per disposable template) to opt into the potentially less safe setup.
So that’s a way of justifying the special behavior for an unnamed disposable launching another unnamed disposable. This special behavior also affecting a named disposable launching an unnamed disposable seemed to me like it was just a side effect of the implementation. But in the PR discussion, people appreciated consistency in the behavior of disposables, whether named or unnamed.
FWIW, try clearing its ‘private’ volume: How to initialize the default dvm template - #4 by rustybird