Sleazy Fork

Currently the limit is 2MB, but maybe it can increased to 5MB? Here's a minified script (deleted) that exceeds 2MB if the author compiles it without minification. I suggested the author to split a part of it into a library + @require but not all scripts can split their code...

That script is a bad example, it shouldn't be bigger than ~50-100Kb.
But I see that there can be legit ways for a script to reach the current limit, for example one of my maintained scripts is over 600KB now, if I knew nothing about nuances of image compression it would be at ~2MB.

There is a script left this website because of the size limit, it's Bilibili Evolved.

This script was previously released on this website, after it reaches the limit, it is released to Github. Now the code of this script is minified, the script size is 2.48 MB.

"One of the core principles of Greasy Fork is that the user must be able to inspect the code in a script."

Already a 2MB script bundled in one file is not very fun to review (unless most of it is explanatory comments). If you want to keep that principle strict, keep the size limitation.

If you on the other hand want to be the go-to-place for all popular user-scripts, you could consider an optional listing with a warning like: "This script is exempt from size rule and is not thoroughly reviewed. Use at own risk." Perhaps that's no difference from any other script though. When minify helps performance, you can exempt that restriction as well. Does that open for a surge of malware on the site? Does the current rules prevent that? The exception would probably be granted to scripts that have been on the site some time, but outgrows it.

There is a script left this website because of the size limit, it's Bilibili Evolved.

Seeing the git I think is better than to review the final user-script in this case. The way the project works long-term can mean more than the actual code. They also share different variants of the script and have their own update mechanism, from what I saw. They seem to fit fine on github and only lack GF for as marketing. If GF wants to be the "go-to list for scripts" well-maintained scripts should get exceptions and be included. The exception could however be that they're not even hosted on GF, but only listed as external scripts.

not all scripts can split their code...

I don't see why not? Perhaps a specific library won't get wider usage, but splitting should be possible with some work? Rarely reviewed libs are possibly not an improvement from the point of safety however, so enforcing the rule might also make the code worse. Setting a clear limit and possibly agreeing that not all scripts are welcome saves moderators from the burden of trying to fix incoming scripts.

[without] image compression it would be at ~2MB

A bit off topic, but much of that script seems to be config. It is allowed to load JSON freely so if ever a problem, put that in a separate file and require directly from github. And for the icons, several are repeated. Isn't it better to refer to named resources that can be cached and reused?

Already a 2MB script bundled in one file is not very fun to review (unless most of it is explanatory comments). If you want to keep that principle strict, keep the size limitation.

Side loading parts of a script would make it harder to review it (and harder to maintain), but before that I definitely would remove all the comments from a script, and apply other uglifying methods, splitting a script is the last resort for me, plus, deleting is easier than writing... To tell you the true, I would never split it, I simply would not update a script on GF anymore. I maintain scripts for myself, them fitting the needs of the others are not so important for me.

A bit off topic, but much of that script seems to be config. It is allowed to load JSON freely so if ever a problem, put that in a separate file and require directly from github. And for the icons, several are repeated. Isn't it better to refer to named resources that can be cached and reused?

I know that it's better, in theory... In practice it's more convenient as it's now, and it would require to rewrite some parts of the script.

OFF TOPIC:
OUJS stops taking the scripts ~900Kb, you can still import them if they are less than ~1Mb.