You’ve covered all possibilities, by the look of it. I know some of the PDF stuff was reworked in 10.12, but I’d be surprised if the action is doing much different from my script earlier, so that probably doesn’t explain it. It may well just be improved handling of ASObjC methods that are slow to return. I guess I should hunt down some others to test the theory.
Ahah! – sounds like it. So does it run fine in Script Editor if you hold down the Control key to force it to the foreground?
Strange that it’s changed in 10.12, though.
Yes! 
So presumably it’s also happy with this:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "Automator"
use scripting additions
set InputFolder to ((path to desktop as text) & "Temp:Test JPEGs:")
tell application "Finder" to set FileList to every file in folder InputFolder as alias list
repeat with i from 1 to count FileList
set item i of FileList to POSIX path of item i of FileList
end repeat
--
set workflowPath to POSIX path of ((path to desktop as text) & "Make_PDFs.workflow")
set workflowURL to current application's |NSURL|'s fileURLWithPath:workflowPath
if current application's NSThread's isMainThread() as boolean then
its doMainThreadStuff:{workflowURL, FileList}
else
my performSelectorOnMainThread:"doMainThreadStuff:" withObject:{workflowURL, FileList} waitUntilDone:true
end if
on doMainThreadStuff:theArgs
set {workflowURL, FileList} to theArgs
set {theResult, theError} to current application's AMWorkflow's runWorkflowAtURL:workflowURL withInput:FileList |error|:(reference)
if theError is not missing value then error (theError's localizedDescription() as text)
end doMainThreadStuff:
Even Script Debugger likes it ” from the point of view of not hanging. If theResult’s needed for anything, it’s not available this way. But given that the thread problem only occurs when the script’s run in an editor, and not at all in Sierra, your original script should be fine and one only needs to downgrade to Script Editor or ASObjC Explorer to test it. 
It turns out that although the handler doesn’t return a result when it’s executed on a different thread ” and in fact the AS error generated in it is invisible to the main script too ” the script can access the information through properties or globals:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "Automator"
use scripting additions
--property theResult : missing value
--property theError : missing value
global theResult, theError -- For results from a handler possibly run on a different thread.
set InputFolder to ((path to desktop as text) & "Temp:Test JPEGs:")
tell application "Finder" to set FileList to every file in folder InputFolder as alias list
repeat with i from 1 to count FileList
set item i of FileList to POSIX path of item i of FileList
end repeat
--
set workflowPath to POSIX path of ((path to desktop as text) & "Make_PDFs.workflow")
set workflowURL to current application's |NSURL|'s fileURLWithPath:workflowPath
if current application's NSThread's isMainThread() as boolean then
its doMainThreadStuff:{workflowURL, FileList}
else
my performSelectorOnMainThread:"doMainThreadStuff:" withObject:{workflowURL, FileList} waitUntilDone:true
end if
-- Check the results _after_ performing the handler.
if theError is not missing value then error (theError's localizedDescription() as text)
return {theResult, theError} -- Both values returned here just as proof of concept.
on doMainThreadStuff:theArgs
set {workflowURL, FileList} to theArgs
-- When this handler's run on a different thread from the main script, no errors or results it generates get back to the script.
-- So instead set globals or properties to the relevant information.
set {theResult, theError} to current application's AMWorkflow's runWorkflowAtURL:workflowURL withInput:FileList |error|:(reference)
--if theError is not missing value then error (theError's localizedDescription() as text)
--return theResult
end doMainThreadStuff:
theResult can be coerced to alias in El Capitan, but I don’t know if that’s also true in Yosemite.
What the result is, and it’s class, is going to depend a bit on the workflow, obviously. In my example here, it returns a path as as an NSString. But the whole thing with what actions return is a bit murky, because Automator often adds invisible coercion actions (.cactions) between them to make stuff work.
Ah yes. Of course. :rolleyes:
In fact the return in my case was being passed through (but not altered during) the Run AppleScript action I’d added to the workflow to indicate progress. I was getting an NSAppleEventDescriptor. Having disabled the Run AppleScript action, I’m now getting an NSArray containing a single NSString, which can’t be coerced to alias on my machine.
Oops, my path string was in an array, too.