From my perspective, one of the great things about the TEXMAP extension is that it allows users - who may or may not be experienced part authors - to create custom stickers / printed parts without modifying the underlying part geometry. (Indeed, one of my current projects is creating a graphical interface for doing just that.) So, if we assume users can decide to stick any arbitrary PNG file to any arbitrary part, the results of doing so ought to be well-defined. 
Plus, it just makes sense that if you're only decorating a small area of a large polygon, you shouldn't have to create a gigantic, mostly-transparent PNG file in order to represent that small area with sufficient detail. And you shouldn't have to, say, replace a cylinder primitive with a bunch of quads solely because you want part of the cylinder to be textured and part untextured.
Your point about rope textures is an interesting one; in some cases it may be helpful to have textures that automatically repeat. But I feel like that is more of a "material" property that would be better expressed through COLOUR extensions, rather than a semantic property to be encoded as part of the part/model file.
As far as texture orientations go, maybe I wasn't clear. We have two possible definitions for the V coordinate, depending on whether we treat the first or the second control point as the origin. There are also two possible definitions for the U coordinate (if we are looking in the positive V direction, does increasing U correspond to clockwise or counterclockwise movement?) Probably it should be defined in a way that places the texture in its natural orientation on the cylinder exterior (meaning it'd be reversed on the cylinder interior), but the important thing is that it should be defined by the spec.
For the sake of a concrete example, here is a test model showing a few different cases for cylindrical texturing, and the resulting rendered image (not sure how to post an image inline, but I'll attach it as well.)
Plus, it just makes sense that if you're only decorating a small area of a large polygon, you shouldn't have to create a gigantic, mostly-transparent PNG file in order to represent that small area with sufficient detail. And you shouldn't have to, say, replace a cylinder primitive with a bunch of quads solely because you want part of the cylinder to be textured and part untextured.
Your point about rope textures is an interesting one; in some cases it may be helpful to have textures that automatically repeat. But I feel like that is more of a "material" property that would be better expressed through COLOUR extensions, rather than a semantic property to be encoded as part of the part/model file.
As far as texture orientations go, maybe I wasn't clear. We have two possible definitions for the V coordinate, depending on whether we treat the first or the second control point as the origin. There are also two possible definitions for the U coordinate (if we are looking in the positive V direction, does increasing U correspond to clockwise or counterclockwise movement?) Probably it should be defined in a way that places the texture in its natural orientation on the cylinder exterior (meaning it'd be reversed on the cylinder interior), but the important thing is that it should be defined by the spec.
For the sake of a concrete example, here is a test model showing a few different cases for cylindrical texturing, and the resulting rendered image (not sure how to post an image inline, but I'll attach it as well.)