I want to use a source filter because I think it's romantic that my LyX file could itself be a Perl script. But I disagree with the premise of your question.

Source filters have all kinds of mis-uses, but the string eval approach that you suggest is actually more fragile than writing a source filter. It's not like source filters could trigger segfaults or anything. The code-extraction logic, which is the most fragile part of this whole endeavor, is the same whether working with a source filter or a string-eval script. The difference is that source filters are chained but source filters are not applied to string evals. If my in-LyX code uses source filters (hint: I use PDL::NiceSlice, probably the only syntax-modifying source filter that works properly), a string-eval approach is a far bigger headache that a source filter. I would have to try to scan the code before evaling it, and if I detected a "use PDL::NiceSlice", I would have to apply the string transform code, but only between the "use PDL::NiceSlice" and the "no PDL::NiceSlice", respecting comments and pod cuts. (I've done something similar with App::Prima::REPL.) No thanks. I'll let Perl figure that out for me, by using a source filter on my end.

You don't state why you think source filters are fragile, but the typical problem with source filters is that they try to add syntax extensions to Perl, and thus need to do their own Perl parsing. Since no source filter is smart enough to actually parse Perl, it's very easy for the source filter to fall back on dumb regexes. This introduces all kinds of subtle bugs, which cause so many headaches and lost hours that it's usually better to avoid the syntax-modifying source filter. PDL::NiceSlice has had these kinds of bugs filed and fixed, so I trust its operation and use it frequently. The source filter I propose has no substantial edge cases because the LyX-Code delimiters are unambiguous: the content of LyX-Code sections escape material that might have led to ambiguities.