In my opinion, even more problematic than possibly running unsafe code in a flyweight executor on the master is the fact that these flyweight pipeline threads perform a full checkout of the target repository - at least when using Git as the SCM. So if one has a relatively large code repository containing product code - say several gigabytes - and they want to store their Jenkinsfile with the code so they can leverage the MultiBranch options in Jenkins Pipeline, they end up with many copies of their entire codebase being checked out on the master, possibly causing the master to run out of disk space. Add to this the fact that these "temporary" workspaces created on the master by the flyweight tasks are not automatically deleted when not in use and there is no way to purge them from the Jenkins dashboard and you are just asking for problems. This isn't a case of whether this will become a problem as much as it is an issue of when it will become a problem.
In my opinion, Jenkinsfile's stored in SCM should be checked out on an agent as a typical freestyle job would do, and a default "node" allocated by the executor that launches the script contained therein for the node on which it is already running on. Then the rest of the Jenkinsfile could be processed in place without requiring any sort of flyweight executor at all, and avoiding the issues with having multiple checkouts of the same code spread across a build farm. Also, I think this would be inline with how some other more modern continuous integration servers work like travis-ci, so it's not without precidence.