It looks like the module can talk either serial or USB. I didn't see any mention of Ethernet in the quick writeup.
Either will work, and there are issues both ways.
RS-232
The serial will need a converter that goes between the logic level signals of the module and the RS-232 signals of the PC. There are chips that do this, so this is no real issue if you are making your own PCB anyways. For more details, see the RSLink2 product that I sell. That page also links to the datasheet of the converter chip used in the product (Yes I know google complains about that page. It's a false positive. There is no malware on our site.).
In software, you communicate via a COM port. Your application can directly talk to the device. There is no library or driver needed. However, you need really good specs on the serial communication protocol.
USB
Electrically, USB will "just work". In this case, the complication is in the software. A driver in the OS for the device will be needed. If the company supplies you with a driver and then gives you proper specs for calling it, then this may be the best solution. However, in my experience a lot of such drivers are of questionable quality and they almost never give you proper specs to communicate with the driver.
Usually you get a host library and a driver as one package. That by itself is reasonable enough, but often, even usually, the library is of poor quality and the documentation no better.
Some hardware vendors will add USB support by slapping on a FTDI or equivalent chip to a existing serial interface. That gives you the worst of both worlds. You still have the issue of knowing the COM port, and you don't get the inherent device ID and enumeration features of USB. If USB is supported as a afterthought like this, you might as well connect directly to the real underlying serial port.
Conclusion
Electrically, USB should just work and RS-232 can be made to work easily enough. The decision comes down to how good the documentation of the low level protocol, the driver interface, and the library interface are. Have a private talk with a field engineer and try to determine how solid each interface is, how the company plans to proceed in the future, a honest assessment of the driver and library quality, etc. And of course ask for all the documentation up front and read it carefully from the point of view of writing a embedded app trying to drive this device. That alone may dictate one interface over the other.
