On the security aspect, I wonder how is this site affected services that do domain ownership verification [1] where they assume that only a person who owns the domain can edit dns records. I think letsencrpt ACME protocol [2] does it for SSL certs too. This site does create a subdomain for every user, so may be these issues don't apply.
Generally a dot is used as a barrier for these, because otherwise you need to have an infinite (and changing) list where users are allowed to register subdomains. .ac.uk vs. .com, etc. Not to mention that there are some of these domains where the policy is changing and there's both delegates and toplevel domains.
If you don't trust across separator boundaries you're mostly safe. That is, mytxt.foo.com shouldn't be blindly trusted for my.subdomain.foo.com nor mytxt.subdomain.foo.com shouldn't be trusted for foo.com.
IMO the biggest concern is with organizations that blacklist domains for various reasons, because they are not eager to just build very fine-grained blacklists.
One inconvenience is that although RFC8657 explains how to tell a CA that it must use particular methods, the most obvious public CA (Let's Encrypt) has not shipped RFC8657 support. So you can write a CAA record which says "Only Let's Encrypt may issue" or indeed say "Only Sectigo may issue" but you cannot write a record which says e.g. "Only Let's Encrypt may issue, and they must use the tls-alpn-01 method". Or rather, you can write that record but it won't work.
Now, there are a bunch of things you could do about that, and I believe this cool toy does one of the obvious ones: Don't have any certificates for the problematic domain. The web site isn't in the domain you can mess with. But it would be nice if Let's Encrypt got to this, periodically I check so far each time somebody has pestered them for RFC 8657 recently, so I don't pile on since that's unhelpful.
[1] https://support.google.com/a/answer/183895?hl=en
[2] https://letsencrypt.org/docs/client-options/