I don't think it's that we have closed minds. More that we recognize that this is a different tool than UFT/QTP or Eggplant or whatever you may be used to using: different tool, different architecture, different implied methodology. You're using the tool so someone, somewhere, made the decision to use this tool over the others for some reason. Agreed, there are always improvements to be made to applications and tools and such (hence why SmartBear does let us users make and vote on feature requests), but going from one tool to another means learning how to do things differently... writing code in Visual Studio, while it has some similarities, is different than writing code in NetBeans, and not just because the code language is different... and NetBeans is different than Eclipse...
The architecture of launching a test from one machine to execute on another machine requires a variety of security setups, parameters, etc... Basically, TestComplete needs to create an RDP connection to that other workstation, verify that the TestComplete/TestExecute service and/or application is running, and then tell that other workstation to execute those commands. In their development over the past number of years since the Network/Distributed testing feature has been added to TestComplete, the documented requirements were noted as necessity in order to make it work cleanly.
As for QA environment as AlexKaras mentions... that's why it's a good idea to set up a different OU in your AD for your automation test machines that is different than the rest of your workstations and then limit access to those machines to the QA people who need access. This allows you to set up custom machine and/or user group policies for those machines without compromising your corporate security. This is what I've done at every job I've held... and it wasn't TestComplete at each one. Just the simple task of manual testing means I need to have access and abilities on my test environment that no IT security professional would DREAM of giving me on my own workstation. Compartmentalizing your "clean room" workspace for testing allows for this flexibility... as well as allows you to isolate those machines in other ways so that, if something should go horribly wrong there, you won't adversely impact the "real world".
I used to work in electronics manufacturing before I started pounding on test automation... and NEVER did we allow our QA lab to actually interact with the production line nor did it actually interact with the actual operations of the plant (e.g., automation/manual test environments separate from production environments and even separate from the workstations used for regular business like writing e-mails... don't want to use our "live" exchange server for testing applications that may crash the server). We drew our samples from the production line and brought them into our lab (e.g., taking a release candidate from the developers and deploying in a test environment) and then ran our QC checks against those samples in a completely clean and isolated environment. We even had further separation within our QA lab so that we would prevent cross contamination (e.g., load testing machines running performance tests are configured differently and isolated from functional regression so as the data from one would not pollute the other).
What SmartBear suggests within their requirements is well within keeping of best practices regardless of whether or not you're in manufacturing or in software development. You build your environments in such a way that you can control them according to the particular business needs without adversely impacting other environments.
Now... all that said, the offer still stands... if you need help getting this to work, we're more than happy to help. Specific examples, questions, etc., would go a long way in getting you up and running. But expecting TestComplete to act the same as UFT out of the box I don't think is going to happen any time soon. There are ways of performing the same tasks but you may need to implement those tasks differently.
