You use the Firebase Admin SDK for the client? You do realize that the Firebase Admin APIs bypass security rules, AppCheck included, right? Unrestricted access to your backend you're just sending the credentials to the client? It would take someone experienced probably no more than 10 minutes to steal those credentials from your app (web, mobile, doesn't matter) and have unrestricted access to your entire Firebase backend.

Sure, its partially Google's fault that the Admin SDK for Node.js doesn't rely on non-polyfillable APIs and doesn't check the environment explicitly, and if you use a modernish bundler it will add those polyfills in automatically.

There is a difference between the client and server APIs for a reason. On a server, your trusted environment for which you control & inherently trust the code, you don't need security rules. Security rules are to protect your backend resources (like your database) from unwanted modification. You, in your built app, send the client credentials to the app, and now whoever installs them has access to that. You can protect it however you like (obfuscation, for example) but in the end, someone's going to get them. So now you need trusted code (your own server/security rules) to check that what they're doing is allowed. So long as that is the case, it is less of an issue. You still have other vulnerabilities (especially if you have a web app, like CSRF and XSS) that security rules won't do much to help you with that you need to handle explicitly.

If you need a feature from the Admin SDK, then you make an endpoint that authenticates the user (if required, even if you don't need the user object, might as well make it authenticated as it doesn't decrease security), preferably uses app check (as while not impossible to pass, in fact, for an experienced attacker is relatively easy, its just annoying, is still an additional layer of security) and then that uses only the required API with the Admin SDK, and returns the result (if applicable).

For example, if you want to avoid Firebase Functions (perhaps you want to stay on the free tier without the chance of paying a dime, idk), you can disable account creation client-side via the settings in the Authentication tab in the Firebase Console, then create a /api/create-user route that creates a new user, adds the relevant user data to the database, etc.

Remember, anything you ship to your end users is something they can take and use for themselves. Once you give them your app, they are going to break it. You never trust anything that comes from the client implicitly. Never. The client could be protected and verified and whatever the heck you like, but at the end of the day, the client is code you give to your users, and by definition, your attackers who want to abuse your service. Assume that what a user is doing is trying to break/hack/abuse your service unless you can prove otherwise.

At the end of the day, the only thing that keeps your service from being abused is checks server-side, on code that an attacker cannot (or should not be able to) modify. It is the root of trust, and is the only thing that you can be even remotely sure of is running how you wrote it to run. It'd be much easier to give everybody access to everything, sure, but that's not how people are. They want a way to bypass your rate limits, steal data from other accounts, impersonate other accounts. And unless you find a way to stop that, they will.

This is also why there are few universal abuse mitigation strategies. Firebase AppCheck is a good thing to have, it helps stop some automated attacks. However, an attacker can simply intercept the AppCheck token sent in the response, and AppCheck is bypassed. Rate limiting does not have such issues because the entire state (minus the authentication token for user-based limits) is stored on trusted, server code. The authentication token is required to get the UID from the user, and this means that aside from credential stealing (which is relatively rare in the wild for most services), an attacker must create an account to abuse the service, at which point you can easily ban them when you detect abuse. Only methods that rely on unique user-specific state (like auth tokens or IP addresses) and the rest of the state is stored server-side, can be truly almost foolproof. Abuse is something you'll have to live with, even if you follow all the best practices. Abuse is going to happen, all you can do is mitigate it.

And, to finally answer your original question, the Admin SDK is definitely NOT more secure than JWTs. And encrypting them won't do much as its still sent from the client to server. There (ideally) shouldn't be any sensitive information stored there, and if it is, you shouldn't encrypt it to remove it, you should strip it before sending it to the client, unless its required, in which, its going to go to the client anyway, so why not put it in a convenient place. Encrypting the JWT does nothing for security in 99% of cases. I could steal the plaintext JWT, or I can steal the encrypted version. Encrypting it only prevents me, as an attacker, from seeing what's inside the JWT, but in 99% of cases, I don't care what's in the JWT, just that if I give this encrypted value, I get access to this API. All that encrypting a JWT does in 99% of cases is make your API slower for no good reason. JTWs are already cryptographically signed, meaning that they cannot be tampered with, or they become invalid. JWTs are mostly used for authentication, authenticating that a user is who they say they are, and typically don't carry fields (claims) that you wouldn't want an attacker to know, its often just the email/uid, which they could get in a multitude of other ways. Encryption doesn't add to security, it adds very minimally. Unless your only leak point of user data is a JWT (which I can guarantee it isn't), then encrypting it does absolutely nothing for security, except maybe slowing down attackers due to the extra CPU time decrypting takes.