There’s definitely a benefit to vendor provided solutions like less time to implementation, reliability (in some instances), support and even system testing docs.
The challenge is that sometimes you have to write an instrument driver, sometimes you have to write a software driver to control the hardware, and sometimes you have to write both. 
You can create scripts, exe’s or even DLL’s that you just load! (Tons of options!)
However my preferred practice is to implement abstraction layers around all external APIs, regardless of their origin. This typically involves creating service wrappers that normalize vendor-specific interfaces into consistent internal contracts. I prefer architecting these as RESTful web services with OpenAPI/Swagger documentation, which provides several benefits: standardized endpoint documentation, automatic client SDK generation, and a foundation for building responsive web applications or MCP tools. This approach also facilitates microservice architectures and makes it easier to swap out vendor implementations without affecting downstream consumers, plus you can add observability layers and even logging layers to really bring your lab into this century.
With that said, you should try on your own (with Claude Code + context aka docs) and then try other solutions like this one: Introducing the Connector-Factory: a python template for kickstarting device integration with UniteLabs CDK