However, as a rookie in the field of information security, it's hard for me to pinpoint the arguments against running this script if it on the surface (i.e. browsing through the code) looks trustworthy.
If you're a "rookie" in this area, and you're talking to people with even less experience than you, then the obvious question is: what makes you confident that you could spot malicious code? Unless the scripts that you're looking at are trivial, then it's not necessarily easy to determine whether or not they're malicious.
I've not seen a Python specific version of it, but there have previously been competitions to create intentionally backdoored code in other languages (such as the Underhand C Contest, which can be a good illustration of how hard these kind of things can be to spot. There have been some more formal papers on this subject as well, which give good examples in other languages. And this is before you even get into the realms of dependencies (and the fact that anything outside of the Python standard library should be considered questionable).
Properly evaluating code for security issues is a complex and specialist field, and laypeople are not in a position to do it in the vast majority of cases. If you can show them that they're not as good at is as they think they are (for example, by showing them an example of intentionally backdoored code that they think looks safe) that may make them re-consider their abilities.
How can I effectively motivate to a layman that they should avoid this kind of scripts, by outlining to them the potential risks?
When people are deciding what to do, they evaluate the perceived risk against the reward. They believe that the risk is low (based on an overly optimistic assumption about their ability to identify malicious code). So if you can't change that, the other approach would be to reduce the "reward" from doing this, by providing them with a better alternative.
Laypeople are in a much better position to make this kind of decision based on non-technical factors (such as whether the script is produced by a company, the reputation of the users involved, etc) than by trying to read the actual code.
Rather than "don't use scripts for this", you're much more likely to have success with "use this script that's been properly reviewed and posted by someone trustworthy".