So, as it stands, there's not much reason someone would know to optimize their avatar except to view tutorials, and to take action proactively. Unfortunately, a lot of new users are... well, new, so they don't know how important having at least a simple optimization pass on their avatar can be for other users.

A lot of proposed solutions involve "forcing" their avatar to a more-performant placeholder. However, I believe this goes against a core tenet of VRChat-- your avatar is your identity, and it can define you in a lot of ways. Robbing that individuality without user choice seems like the absolute worst solution.

Personally I believe the best approach for those sorts of situations is to notify the user that their avatar is rather "heavy" and to provide them advice to seek assistance in optimizing their avatar. It isn't too difficult to do nowadays (merging materials, doing Texture Atlasing, merging meshes, limiting use of DynamicBones), and I think it is a much better solution to tell the user "Hey, you're causing some serious lag. Fix your crap, here's some community-created guides." than to rob them of their individuality. Robbing individuality from someone because they haven't learned how to merge materials yet doesn't seem... good?

A good amount of this also stems from misinformation. Many users believe that lag is caused by polycount, or by their GPU being over-utilized. This is not true. VRChat lag, in the current version, is 99.9% CPU-bounded. For a user running minimum specs, their GPU is never going to be the bottleneck-- it will always be the CPU. Therefore, it is most beneficial for us to focus on optimization that affects CPU-bound processes (draw calls, dynamic bones, and eventually IK optimization).

TL;DR:

I think the best solution is probably a build-time check on material count, dynamic bone count, mesh count, and general draw-call count (to catch multipass shaders) that would be similar to the polycount soft and hard limits. This would let users know ahead of time that, hey, your avatar is potentially problematic. This system should NOT reward you (or punish you!) for sticking within soft limits. That encourages behavior like "we only allow avatars with less than 5 draw calls and no dynamic bones in this event", which is absolutely no bueno.

As a side effect, we could also lift the limit on polycount, as GPU utilization is usually sub-50% for most users. I believe a limit of 65,535 would be best, as that is the most tris Unity will allow in a single skinned mesh renderer.

I know several users (TCL and I talk about it quite often) have been trying to track down precisely what is causing performance issues, and creating methods to work around it. The community has been pretty proactive in this area. If y'all (as in, Ron and team) need some help or some input from us, I'm sure we'd be glad to mince some words on the subject. :)