This is unrelated to taproot.
The "addresses" field in Bitcoin Core's RPC output was historical legacy that was at best outdated, and at worst confusing. Since 22.0 the field has been deprecated entirely, for all types of transaction outputs. It can (temporarily) be re-enabled using -deprecatedrpc=addresses, but in 23.0 it will be gone entirely. My suggestion is not to use it, because even when it works, it probably doesn't mean what you think it does.
In the modern interpretation, an "address" is a human-readable shorthand notation for a specific "locking script" (scriptPubKey) that can be placed in transaction outputs. Even when the output encodes a multisig policy, there is just one locking script, and thus just one address.
The historical interpretation (before the introduction of BIP16 in 2012, but it lingered on much longer) was that an address is an identifier for a public key. This interpretation is what led to having an "addresses" field in the RPC output; whenever there is a locking script with multiple public keys in it, the "address" identifier of each would be reported in that RPC field.
This historical interpretation is meaningless now, and has been for a long time. The reason is that multisig outputs today don't put multiple keys in the scriptPubKey. Instead they use P2SH (BIP16) or P2WSH (BIP141) to only put a hash of the script that includes all the public keys in the scriptPubKey. This is cheaper, simpler, and somewhat more private. From such outputs, despite being a multisig policy, the RPC output cannot infer the individual public keys, because they are only revealed by the spender at spending time, and for such outputs, the RPC would still only report 1 address.
It is no different for P2TR (taproot) outputs. There are no individual public keys that can be learned from the scriptPubKey, and thus the RPC output would only report a single "address" (the P2TR address).
