You're right - you should not have to do this.
The architecture of having a DLL (DoWork.dll) with a "service reference" (ComanyService) is bad. Unless the DLL has hard-coded the client endpoint (in code) to call the CompanyService for you, then anyone using the DLL will have to try and figure out how to configure the client endpoint for a service they don't know about. Which is what your running into.
The reason this works when you add a service reference directly from your UserService is that when you do this, you get a copy of the ServiceContract from the CompanyService metadata. To prove this, look in the Reference.cs file that get's generated, search for CompanyService and you will find it has the [ServiceContract] attribute, identifying it as a WCF service. Furthermore, you will see the [OperationContract] attributes for the methods, plus any [DataContracts] the service my also exchange. In other words, all these "types" got imported into your project and when you compile, WCF is now able to find these types when instantiating the client endpoint.
If CompanyService is one of your services, then consider extracting out the ServiceContract definition (interface) into a separate DLL. Then, you can reference those types as "assembly references" from the service (CompanyService) and any client applications, such as UserService. At least that way you're not having to add a service reference. But, you still have to populate the .... section in your application for a service you technically may not know the details of. Not the best approach.
A better approach is to move the service dependency out of the DoWork.dll. You could do this by just moving the logic into the UserService implementation.
Or, if you need to keep DoWork.dll independent, then consider wrapping DoWork with it's on WCF Service, which takes a dependency on the CompanyService. Then, from UserService, add a service reference to the new DoWork service. This is more in keeping with the tenants of SOA and will allow your services to evolve independently.