É uma maneira de definir, descrever conjuntos de chaves públicas e condições de resgate que podem ser utilizadas para gastar fundos em uma transação. Isso é útil para facilitar a criação de um grande número de endereços a partir de uma única semente.
Em resumo, são uma ferramenta para melhorar a segurança/flexibilidade das carteiras HD, permitindo gestão de fundos e dos gastos delas
Output descriptors no meu entendimento é você descrever para a carteira na forma de scripts exatamente como você quer quer ela deriva as chaves públicas ou privadas e de qual derivation path, tipo de endereço e etc a carteira deve recuperar. Porque se formos parar pra pensar, somente a seed-phrase não é uma informação suficiente na hora da restauração, tudo bem que a maioria segue o padrão BIP44 ou BIP84 e entre outros, pois esses derivation paths são quase que consenso em praticamente todas as carteiras, então essas carteiras pulam a parte técnica do usuário para que ele não precise lidar com essas informações na hora de criar ou recuperar a sua carteira.
Isso é necessário porque o BIP39 é muito aberto no que tange a sementes, enquanto que no padrão de sementes da Electrum, as sementes electrum carregam nela um número de versão que já indica qual tipo de endereço a Electrum deve informar, enquanto que nas sementes BIP39 possuí o checksum e a carteira ou o usuário que define qual o derivation path e o script de endereço deve ser criado.
Vou quotar aqui a definição de descriptor do dev do Bitcoin Core, o achow101:
A HD wallet is a wallet where the keys are derived in a reproducible way from a single source of randomness known as the seed. The most widely used method for deriving such keys is BIP 32. Since the seed is fairly small, it's easy to back that up and be sure that, in theory, you are able to re-compute all of your private keys in the future.
However, HD wallets make no mention of the type of addresses to create, nor do they specifically state which private keys you are actually using. These change on a wallet by wallet basis. While most wallets follow various standards for choosing which keys to derive and what address types to make from them, just having the seed and knowing that your wallet is a HD wallet is not enough to recover your funds.
Descriptor wallets expand on HD wallets by storing Descriptor strings which specify the keys and the address types to create. Descriptors utilize BIP 32 so that BIP 32 keys and derivation paths can be contained within them to specify the specific keys to use without actually enumerating all of the keys. Descriptors further introduced the script expression notation in order to specify the type of script, and ultimately the type of address, that a descriptor can create. Thus a descriptor is a more complete backup and leaves nothing up to guess work as it specifies both the exact keys to use, and the addresses to create from them.
Descriptors is intended to be a more general notation, so it is also possible to create descriptors which contain just private keys with no BIP 32 derivation at all. They can also be used to represent raw output scripts for cases where the script is nonstandard, and they can be used to create complex arbitrary scripts through the use of the MIniscript language.
Since Descriptor wallets can include BIP 32 derivation, descriptor wallets are basically a kind of HD wallet. But really, they are a superset of HD wallets since they do a lot more than just managing private keys.
A way to think about how these are different is the philosophy that they essentially represent. A HD wallet represents a keys first philosophy where the key is the king. Everything comes from the key - the key exists first, then the script is created from that key.
Conversely, Descriptor wallets represent a scripts first philosophy where keys are inserted afterwards. Descriptors describe a script template in which keys are later computed and inserted into the positions in the script as described by the descriptor. For descriptors, how the key is generated is not that important; they could be randomly generated and put in the descriptor string, or they can be generated from a BIP 32 key and derivation path. All that is required is that the key expressions produce individual keys that can be placed into scripts.
