I'd say yes. OO's big three are encapsulation, instantiation, and inheritance. Since you don't have any privates (*giggle*) you don't need encapsulation (unless you want private *methods* - that's an important distinction), instantiation isn't limited to LVOOP since everything's by-val anyway) and you don't need ingeritance. That said, there's no harm in leaving it as a class - as jgcode said, namespacing could be an issue, and if you're okay with the class as it is, then I don't think you need to demote it.
Hmmmm - that's a good question. I don't think it's an issue. I see a lvlib as a collection of related VIs, whereas a class is a collection of related VIs that act on an object - I'm assuming that you're still going to have an object, right? Like a cluster of something that passes between the VIs? If so, I'd stay with a class - it's easier to manage (the prototype of the object is in the class, not as a separate ctl file).
Using the work "Object" doesn't mean that it must be of type class. If it can be considered an object (eg" a file, something in the real world, a DAQ card, etc) then that's fine. That said, I usually don't use the word "object" in the names of my objects - because that's the type of the input/output. It'be like calling your numeric inputs and outputs "Numeric In" and "Numeric Out" - call them what they actually represent (eg: "Configuration File" or "DAQ Card", etc).