The only other option that I can come up with is to let developers
store the scripts in a special part of version control, in which there
is no quality control (much like GitHub Gists). The risk is that
others will not be able to use the code because they cannot find or
understand it.
How could this problem be solved? Or should it not be solved?
The problem cannot be solved.
There is a big difference between sharing code by word-of-mouth when you overhear that a colleague is facing a particular difficulty, and sharing it simply by putting it into a library to which all have access.
The difference is that, in the first case, you are playing the role of the creator and librarian with implicit knowledge of the problem and the code you have which solves it, whereas in the second case, those roles are not present.
Your general standards of code may be designed to eliminate the role of the librarian in your company, and ensure that the library remains self-navigable to all-comers.
With a huge edifice of long-lived code (as characterises most core software products), time and effort is justified to preserve the ability of multiple generations of workers to continue working with the whole edifice. In companies with a high turnover of staff, a "generation" of staff may be as little as every year or two.
But of course, attaining those "librarianless" standards comes at the price of huge time and effort for those creating the library in the first place, and it still demands significant time and effort from those who later come to use and navigate the library (though not the same effort as re-creating the entire edifice from scratch, which may have already taken multiple generations).
On the other hand, most of these quick-and-dirty scripts will be written to get simple things done quickly - perhaps on a one-off basis. They're not intricate or robust creations.
You say they "save time", but of course this only remains true when they are not written to the much higher, librarianless, standard. They are the personal construction jigs of those who made them - the temporary levers and scaffolding of human effort, not the final durable product.
It should be possible to check them into version control, so that the creator has somewhere to systematically store and preserve them - but it should also be clear that they represent product over which their creator still has oversight.
If you can read their code and immediately see what it does, so much the better. But it is the creator's personal library, and they are not being held at the standard that other people must be able to see what it does without reference to the creator.
This is not a "risk" borne by the team, any more so than the arrangement of personal effects in your house is a "risk" to those who may wish to ask to borrow them. On the contrary, having to index the entire contents of your house, arrange them in a set fashion and provide an instruction manual for every item, is a serious risk to your own ongoing efficient use of the house.
Sometime later you see a colleague working on a similar task. You go "Hey! I made a script for that. Let me look that up. [looks] Oh, it was stored on my previous laptop so I don't have it anymore
. That's a good way to trash efforts, time and money along with the scripts. Isn't it?The risk is that others will not be able to use the code because they cannot find or understand it.
Like any piece of code, we are not familiar with. I think that is a bad reasoning to don't check the scripts into any SCM.