Your email, and one or two from others, does raise an issue we regularly consider: how do we devise a model that at once meets the needs of its (relatively defined) community but is also flexible enough so that others can work with it easily while ensureing that the model does what it can to ensure that data is exchanged in a predictable manner?
You've championed how simple an Open Annotation is and, indeed, it is. Target, body, motivation. But if the body of an Annotation can be anything (any Thing), then that's a pretty big unknown. Not only is it a big unknown, but it is so flexible as to render the body potentially unpredictable and different from annotation to annotation (or at least annotation creator to annotation creator). Exchange is a huge aspect of BIBFRAME and so we prefer to proceed cautiously when faced with such a possibility. We (the library community generally) need to be able to receive data from large numbers of varying entities and the data must be predictable. As painful as rules can be, there's also an enormous amount to be gained from them. You've mentioned the possible problems with needing to guess, or at least test, whether the annotation body is a literal or a resource. How would it be to figure out what we're getting as an annotation body each and every time? Did this annotation creator use DCTERMS or something else entirely? Imagine what code would look like if it had to make sense of the complete unknown.
Is your list of properties anything much more than hyperbole? Probably not but it's hard to deny that a number of those could be shared across all annotations to the mutual benefit of all annotation consumers. We're identifying use cases and what we need to realize those use cases efficiently and predictably. Properties (and Annotation types) would be defined as needed, possibly per Annotation type. Patterns will emerge.
In any event, in the course of writing the above, I visited the Open Annotation spec once or twice. Without crawling back through my email, I have a vague memory of you mentioning that an Annotation processor encountering an Annotation with a literal body would not know what to do with it. I take this to mean that "because there is no 'hasBody' relationship pointing to a resource, then the OA processor would not know what to do with this unknown property." I've two questions:
1) The Open Annotation spec says of the hasBody property, "There SHOULD be 1 or more oa:hasBody relationships associated with an Annotation but there MAY be 0". If the Annotation spec already permits OA Annotations without bodies, either the processor will gracefully treat a BIBFRAME Annotation with only a literal body in the same way or it would also choke on Open Annotation annotations with no oa:hasBody property. No?
2) The Open Annotation spec says of the oa:Annotation class: "All Annotations MUST be instances of the class
oa:Annotation, and additional subclassing is ONLY RECOMMENDED in order to provide additional, community-specific constraints on the model." Can you give me an example of a community-specific contraint?
It's worth noting that I don’t believe we've ever stated that a BIBFRAME Annotation and an Open Annotation are the same thing and I feel that has been an assumption. Perhaps they are the same, but I'm not entirely confident we can definitively conclude that yet. Nevertheless, they are undoubtedly closely similar and we've, all along, entertained alignment with OA, if possible. But, first and foremost, we're interested in a model that best serves the needs of the community of users we envision using BIBFRAME.
Instead of seeing this as zero sum game, it might be more fruitful to ask, "is there a middle ground solution?"