Alright. We need to extract more information about what is actually happening. I will improve the code so that when possible, it will return more detailed error code/error message. I will make a new build available, and let you know here - it should be by tomorrow, hopefully.
In future tests, please go back to using ProgID instead of CLSID, as it seems that using CLSID could be misleading us, or showing a different problem.

This may have to do with how the PHP code is run. I.e. is it hosted in another process (IIS or other Web server) that does not run under your interactive account? If so, what are the user credentials of that process etc.
When you run a regular OPC client, such as Softing, it runs under the currently logged-on user account - and that is easier.
The way to verify this hypothesis would be to simply rewrite the piece of your PHP code into a PHP that can be run from command line, using PHP command-line interpreter (i.e. not as Web page). Then, run your PHP from command line. If it succeeds, the hypothesis is right, and it must be a configuration issue that has to do with processes, user accounts, permissions etc. If it fails, it must be something else.

The error message could be better (made a note: will make it better in next version). Indeed, you do not have to explicitly connect to the machine.
The error is caused by the fact that the component could not initialize any method for remotely discovering OPC severs on that computer. There are two methods: Remote registry, and OPCEnum, and both are turned on by default, so it would be enough if at least one of them succeeds. Remote registry is not really recommended, it is just a back-up method for certain special cases, so let;'s focus on OPCEnum. This is a service that should be present and running on the machine where the OPC Server resides. It is typically installed with the OPC Server, or it can be installed by using OPC Core Components (from OPC Foundation) (or, we install it with our product too - but that's on client side). In addition, DCOM must be enabled on the remot machine, and the OPCEnum component must be properly configured so that other computers can obtain a list of OPC servers on that machine, or transform server ProgIDs to CLSIDs.
Please check first if OPCEnum service is running on the computer where the OPC Server is. Then, run DCOMCNFG and check if DCOM is enabled. Locate the OPCEnum application, and allow launch and access permissions as necessary.
It is also possible to bypass the usage of OPCEnum if you specify the OPC Server directly using its numerical CLSID: i.e. in place of "BACHMANN.OPCStandardServer.2", you would instead have something like "{9996C49F-AB45-4F9E-93CD-3F203CD5F281}" - but a different value, the one that is the proper CLSID for that server. This is, however, kind of last resort, and may not be much of a value, because the problem could be in DCOM configuration, and if the DCOM configuration is wrong of OPCEnum, it can easily be wrong for the actual OPC Server as well.
BTW, have you tried any other OPC client accessing the OPC server in the same setup (between the same two machines)?