the first one looks good. this would need to format the arguments in the proper data types though. numbers, strings, and bools (and possibly userdata variables) should be sufficient for most situations. i know sexps can only return integers but im not sure what the limits are on the type of the argument, or how to get across to lua what type it is supposed to be.
the second one looks like it would be really user unfriendly, but would come in handy if you need to do something that is rather large, like declare a table and fill in its contents. would just assume its a block of text. actually if this had some kind of front end in fred, where it would take a block of script, and break it up into the various parts to parse it as a series of sexp arguments (and reassemble it for editing), it would be about the same as having lua blocks as part of the mission file.
another idea is include lua blocks right in the mission, something like
$lua block name: block1
+script: [
--script goes here
]
and then have it so you can call certain embedded blocks from the sexp.
script-eval-block
--block name
this doesnt directly pass any arguments back and fourth at all. of course that doesnt stop you from reading sexp variables. im not sure it would support a return code either.