Bf 6 Portal Serervers Community Garbage!

I think there are is some nuance missing from the OP.

1. Making a huge map with a huge number of objectives, will naturally perform worse. (video)  I think there is a reason that pushing things to the limit have consequences. I think there is a reason why the developer operates its design within its intended limits. I think any "official" (whatever that means) server which tried the same would have similar problems, the game developer would adjust the servers to fix those problems, and then you wouldn't have the same problems any more either. But that's not where we are. It's the classic problem of designing within the constraints. If the game developer has not yet pushed to this design limit and created the infrastructure to support it, should you?
2. From my experience, the biggest affect on rubberbanding is server up time. You don't have it displayed in your video. Turn on server bar to "always" in your game's system->network settings.  If the up-time is more than a couple of days, the server will rubberband sooner.  If your server is rubberbanding, it will never stop, no matter how many people leave and how few people remain in the server. That is a server problem, but it is a server problem you have some control over. If you host a server, and the up-time is high, immediately leave and re-host it until you get a good (one day or less up-time) server, before people join.  If you cause/allow people to populate a server with high up-time, you are contributing to the problem. It will only perform worse and worse as time goes one. At least that is the only part of the problem you have direct control over.
3. The server rules implemented have a massive effect on server performance and stability. Try to reduce the number of rules and get less fancy when not needed. Reduce use of "configuration variables" and instead hard-code the values into your rules which can be hard-coded. Instead of defining max size, min size, yes true for this, no false for that, as 20 configuration values at the top of your rules, go down through the rules, hard-code the values or choices you decided on, and then delete the configuration variables which are no longer being used. If it isn't a value that changes, it isn't really variable; it's just a waste of resources. Reduce array sizes when unnecessarily big (like, do you need to define all objectives up to Z, when the game is designed for much fewer?). Reduce the number of wait commands and rules stuck waiting on a result.  Reduce the number of times you tell AI to do something, or to check their distance to an object, or wait somewhere, and instead try to put them into BattlefieldBehavior as soon as you can and then just let them do their thing as much as you see it not negatively affect the gameplay. The AI commander usually does a good job. Similarly, do not make the map needlessly large, in order to reduce AI computation. Do you really need to define so many areas and where infantry is allowed and where vehicles are allowed instead of just making the map whatever size and allow the infantry decide if they are bored walking out into an empty desert? Simplify wherever possible and then reduce the rule size computation because of that simplification. Try spawning the AI in once every 2 seconds instead of every second.  Do similar things and think about how a bunch of AI commands might stack up at the same time. Again, try changing the AI to battlefield behavior after they do certain things, so that they won't use up so much computation time or not be as likely to all try to ask for a new objective at the same time. Reduce the number of ongoing rules and combine more rules together when they have the same or non-competing conditions.
4. Try reducing the server population a bit. Does it HAVE to have 64 players? Have you tried 56 or 48 and seen a significant difference in gameplay?  It sucks not aiming straight for the higher goal, but if it makes a performance difference but little game difference, is it worth it?
5. From all indications, consoles are less likely to crash than PCs in this situation. Maybe because the console is better defined and therefore the game's settings will naturally be more restricted and less likely to cause these problems. Or maybe the PC application has design problems. But, whatever the reason, if you use PC, consider whether there are settings you can use to reduce the number of performance problems you experience. I see lots of people on PC pushing the limit of visuals, without caring about compromise.

Until/if they improve the quality of the community servers and fix the memory leak -- or whatever problem causes high up-time servers to run like crap -- or start rebooting servers more regularly, there isn't much more you can do except for try to operate within the limits provided.  I really think the five points I mentioned make a massive impact and completely change something from being either playable or unplayable. And, no, I don't think 30hz versus 60hz servers have a significant affect compared to simple server up-time.

So, no, I don't think it is a waste of time designing custom portal servers.  I think it is more important to consider the intended product and, if the intended product is the biggest anything in the game, design with compromise in mind from the beginning.  Otherwise, there might be a reason why your goal hasn't already been successfully achieved.