As Marc said, SPServices won't have an impact on the cross domain security barriers. Most browsers will prevent scripting of those calls regardless of the connection method you employ. That said, some methods work better than others. JavaScript/jQuery cross domain calls to web services typically don't work well unless you're calling custom web services and have full trust solutions in place. I've seen better luck calling REST and parsing the output than using jQuery to call SOAP.
I've "circumvented" some of those restrictions by storing my JavaScript on the SharePoint system. If you load your JavaScript files from the domain you'll be making the web service call to, technically the scripts live on the same domain and it's less of a problem (unless there's some other firewall rules in place between domains). If they're truly separate domains you also have to deal with full or one-way AD trusts to make sure the correct authentication happens on the SharePoint side.
Custom app on http://app.company.local loads its' jQuery and JavaScript from a library (or /_layouts) on http://sp.company.local, and calls http://sp.company.local SOAP services.
I've "circumvented" some of those restrictions by storing my JavaScript on the SharePoint system. If you load your JavaScript files from the domain you'll be making the web service call to, technically the scripts live on the same domain and it's less of a problem (unless there's some other firewall rules in place between domains). If they're truly separate domains you also have to deal with full or one-way AD trusts to make sure the correct authentication happens on the SharePoint side.
Custom app on http://app.company.local loads its' jQuery and JavaScript from a library (or /_layouts) on http://sp.company.local, and calls http://sp.company.local SOAP services.