At first glance it seemed to me that this wasn't answerable except to say, no, options that seem meaningless can always be found. You can make your own program that deliberately has totally meaninglessly named options. (Of course, even then, you might say they are meaningful in their meaninglessness, if they were deliberately chosen to be meaningless.)
Upon further consideration, however, I realized that the ambiguity in what it means for an option to be semantic is actually an important and useful part of how command-line options are named, and
curl -I is a particularly illustrative case of this.
As muru says, options don't have to be semantic. But
-I option is semantic. From curl(1):
(HTTP) Include the HTTP-header in the output. The HTTP-header includes things like server-name, date of the document, HTTP-version and more...
(HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document. When used on a FTP or FILE file, curl displays the file size and last modification time only.
-i is the short form of
--include, causing the HTTP header to be included. Although
-I is the short form of
--head, it is semantically the stronger form of
-i, in that while
-i gives you the HTTP header,
-I gives you only the HTTP header.
This offers insight into your larger question: there are many different criteria with which one might judge if an option name is semantic. When an option is semantic it might be intentional or unintentional. If you're only interested in whether or not there exists some way to remember the option as though it is semantic, then yes, you can always make up a reason the name relates to its meaning.
Some options are semantic in more than one way. You can make GNU
grep show lines adjacent to matching lines with
-A for after,
-B for before, and
-C for context which gives you both. Thus the short forms of the three options
--context, which are very close to one another in meaning, are also close to one another in the alphabet. Is that semantic?
To pursue this further and get a rigorous answer, you can search applicable standards like POSIX.1-2008. It seems extremely implausible that it prohibits meaninglessly named options, but I suppose you'd have to carefully read the whole thing to be sure. A cursory search does not reveal any requirement that options mean anything. In particular, these official guidelines--required only for commands whose documentation declares compliance with them--recommend various restrictions on how options may be named and the effect of passing them, but they don't mention anything that could be interpreted as a requirement or recommendation that option names make sense. Even if you did find something, many Unix-like systems don't aim for full POSIX compliance...
But that whole line of thinking--consulting official sources to determine if (vendors have to pretend that) every option's name means something--is sort of silly. The real useful thing to know about options is that their names can relate to each other in multiple ways. They can be named after words, after other options, or for alphabetical proximity to other options. Sometimes they're just a letter (or numeral) that happened to be available. Thinking about these ways can help you to remember options, to find options when searching manpages, and to make good decisions about what option names your own scripts or programs should take.
As a final note, it's good to keep in mind that it's not just short-form options that can be named in ways that don't allow you to infer their meaning. For example, the long-form options
mlocate are named semantically in the sense that they both have to do with regular expressions. But there is nothing in the way they are named to tell you that
--regexp means the next argument is a BRE while
--regex means all pattern arguments are EREs.