This feature is available since kernel 5.3, but Raspberry chose to not compile it in supplied kernels.
As I didn't manage to find the kernel configuration file (usually present as /boot/config-xxx or from kernel), I extracted the install image to verify this directly. Here's a comparison of available modules in Raspbian's kernel (from zip image downloaded from official site):
$ ls -1 lib/modules/5.10.92-v8+/kernel/net/bridge/netfilter/nf*
lib/modules/5.10.92-v8+/kernel/net/bridge/netfilter/nf_log_bridge.ko
lib/modules/5.10.92-v8+/kernel/net/bridge/netfilter/nft_reject_bridge.ko
versus a similar Debian kernel for the same architecture:
$ ls -1 lib/modules/5.10.0-10-arm64/kernel/net/bridge/netfilter/nf*
lib/modules/5.10.0-10-arm64/kernel/net/bridge/netfilter/nf_conntrack_bridge.ko
lib/modules/5.10.0-10-arm64/kernel/net/bridge/netfilter/nf_log_bridge.ko
lib/modules/5.10.0-10-arm64/kernel/net/bridge/netfilter/nft_meta_bridge.ko
lib/modules/5.10.0-10-arm64/kernel/net/bridge/netfilter/nft_reject_bridge.ko
As one can see, needed Netfilter support provided by nf_conntrack_bridge for the conntrack part and nft_meta_bridge for the nftables part isn't available (and no it's not built-in either: grep bridge lib/modules/5.10.92-v8+/modules.builtin has no result) on RaspberryPi OS's default kernel. A kernel with these features also enabled has to be built:
It's quite possible other rare features are also missing. For example modules nft_synproxy and nft_xfrm (for IPSec filtering) aren't present either.
Meanwhile, one can still use the deprecated method (that is intended to be removed once feature parity is achieved), which also affects nftables for better or for worse: the br_netfilter kernel module. But native nftables lacks specific support for this method, since it's designed to use the newer kernel 5.3 method. In particular it has no equivalent for iptables' -m physdev --physdev-is-bridged.