Not really -- more that you shouldn't use an AppleScript when you can do the same with a few KM Actions. That's because it takes time and resources to instantiate the AS environment -- why replace a routine of a dozen KM Actions that takes ~12ms to execute with an AS that takes ~40ms just to ready, never mind run.
But AppleScripts run "as fast as they can", compared to KM's "one Action per millisecond", so the more you do in your AS the less relevant the instantiation time. And if you are already using AS -- your DEVONthink import -- it makes sense to everything in one script with a single instantiation.
Robustness and speed are other reasons for using AS to do your "Save As..." step. You can do it with KM Actions -- it's been covered here many times, and here's a recent thread about it -- but the basic pattern is
- "Select a Menu Item" to "Save As..."
- Wait for the dialog to be ready for input
- "Insert by typing/pasting" the new file name
- "Simulate a keystroke"
⇧⌘Gto open the "Go to location" dialog - Wait for the dialog to be ready for input
- "Insert by pasting" the path you want to save at
- Click the "OK" button
- Click the "Save" button
The good thing about learning this pattern is that that it works (with maybe minor modifications) for any app that uses the standard OS "Save" dialog -- AppleScript solutions are generally app-specific, assuming the app is scriptable in the first place.
Similar would be true for importing into DEVONthink -- you automate what you'd do, manually, in the UI.
But given that you've got a) two AppleScriptable applications, and b) an AppleScript that works -- I'd leave everything as it is!
If I was to change things -- I'd change the approach taken. Why open the file in Numbers and immediately "Save As..."? I'd duplicate the template file, named appropriately, then open that duplicate. I haven't got DEVON to test against, but something like:
