I wouldn’t bother. In fact, you can do away with the use AppleScript line completely. It’s not needed, and the only corollary to omitting it arises if you execute a script using a version of AppleScript that predates the version in which the script was written iff that script contains terminology or makes calls to commands that were only introduced in a version of AppleScript that came after the one attempting execution.
The current (latest) version of AppleScript is 2.8, and so shouldn’t lead to problems of the nature i just described. If you are running on an earlier version of macOS witb an earlier version of AppleScript, were there ever to be any unrecognised commands or terminology used, it’ll either just fail to compile or, by sheer fluke, might possibly compile, which will only lead to the script throwing an error during runtime.
If I were to try and quantify the actual value a use AppleScript line adds to a script, I would estimate it to be close to, or exactly, 0.0.
As to the sporadic nature of your problem, it sounds like the problem is with FastScripts. Therefore, I strongly recommend submitting a bug report via their (his) website, which will, firstly, lead to the confirmation or ruling-out of FsatScripts as the culprit; and, secondly, if it is the source of the problem, allow the creator to be made aware of it and release a fix.
However, to cover a few more bases, you can do a little further debugging. If this were me, I’d be keen to comment out the SMSForder property declaration and see whether FastScripts executes the remaining lines without complaint. If possible, see if you can take steps similar to the ones you described that leads to the referencing error arising, but in the absence of the SMSForder property declaration (so, for the time-being at least, you can keep the use AppleScript version "2.5" line, amending as necessary to try and generate the error). Since it appears at present that the error-throwing line is the one that would no longer be present, we’ll be expecting the barebones script to run error-free.
That being the case, then I’d want to see whether the SMSForder class can be referenced safely at runtime without causing any problems. So, with the declaration for property SMSForder : ... still omitted (or commented out) from the script, you can add this line to the end of the script:
return the current application's SMSForder's frameworkVersion() as text
which should return "1.3.4" (I’m assuming).
On a minor note, you should move the load framework command down a couple of lines so it sits beneath your property declarations. Mostly, this is for neatness, but it’s a good idea to be disciplined in how you layout and structure your code, which includes the order in which groups of related commands appear. It will aid readability, which in turn makes debugging easier, and it will surprisingly help reduce the likelihood of error-prone code. There’s also one or two specific situations where the ordering of AppleScript code makes a big difference in how the script is executed, namely with respect to any top-level declaration that ends up being evaluated (even partially) at compile-time, as these will each affect any other similar top-level declarations that make reference to one another.
The reason this crossed my mind is because the load framework command returns a reference to the SMSForder class instance, which did give me pause to think about any effect this would convey having the property declaration for the SMSForder class reference appear on the line directly under it. But the answer is that it wouldn’t convey any effect, since load framework is a command call, hence the call isn’t going to be made until runtime. Nonetheless, having these lines appear in an order that doesn’t reflect the order in which they are processed by the script is a little disorienting, which is why I would typically move the load framework command down so it is beneath all the property declarations and lexicographically associated with the other parts the script that together would form the implicit run handler.
It follows that having a specific property declaration for SMSForder is somewhat redundant, as your header could easily be reduced a smidge to this:
use framework “Foundation”
use scripting additions
use BridgePlus : script “BridgePlus”
use script “RegexAndStuffLib”
set SMSForder to load framework
I suspect doing this would also circumvent whatever issue FastScripts is having (which you should still report to the developer).