I think the answer is fairly straightforward. First, you have done exactly the right thing...
Firewalld is a pure frontend. It's not an independent firewall by itself. It only operates by taking instructions, then turning them into nftables rules (formerly iptables), and the nftables rules ARE the firewall. So you have a choice between running "firewalld using nftables" and running "nftables only". Nftables in turn works directly as part of the kernel, using a number of modules there, which are partly new, and partly repeat the "netfilter" system of kernel hooks and modules which became part of the kernel around 2000.
It gets quite confusing to run firewalld and nftables (formerly, iptables) in parallel, though I believe some people do so. If you were accustomed to run your own iptables rules anyway, it is the perfect solution to have converted them to nftables rules, and let them be the rules of your firewall. The best thing indeed is to completely disable and preferably mask firewalld - to be slightly pedantic, you can run:
sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask --now firewalld
There is nothing else you need to do. I myself run directly with nftables too. I find that much more transparent than using a front end (there are others than firewalld of course) - it gives you a complete understanding of what you are doing, and you can easily get a complete review of the effect of your rules by running sudo nft list ruleset > /etc/nftables.conf . And the use of separate nft tables in /etc/nftables.d is a nice and easy way of tracking what you have done, and where things are...
It was subsequently asked in comments by @eriknelson why you would mask a service at all. This is done, afaik, for practical reasons of user experience, and to protect against mistakes and hard-to-find bugs. It is highly undesirable to have more than one firewall system running, as the results for most people would be unpredictable, and it is unlikely that you get clear error messages from any firewall about its interaction with another firewall that is not expected to be there. The kernel however tries to process whatever it is given. If you use either nftables or iptables, you should not use firewalld. Or ufw. Or any other higher level system. And if you mainly use a higher-level firewall like firewalld, you don't like to mess around with the detailed low-level instructions (although occasionally it is done for a particular difficult situation that you find it too difficult to specify in the more high-level firewall).
When you mask a systemd service, you can neither start nor enable it straightaway. If you find / realise that the service is masked, you can unmask it - and then do what you want. This is set up to prevent any such changes made inadvertently or automatically. You can see for yourself if you have masked services on your computer by running sudo systemctl list-unit-files | grep mask
So this situation that you may not necessarily want to remove firewalld completely, but equally don't want to run it perhaps inadvertently, is precisely one of the cases where using sudo systemctl mask xyz.service can come in handy.
I suppose from what you write that you know all this. But I am a bit of an evangelist for nftables, and if others read this answer, they might be helped by these small hints. The documentation of nftables is good, but not excessive.
