First of all, I don't know what you're talking about when you say "It is OK if my item doesn't get published because you don't like." I have no control over what gets published anywhere. I have a hard enough time getting my own stuff published! :-)
As for your argument, I think I see what you're saying. In the purest sense a POJO should have no restrictions on it, other than it is an instance of java.lang.Object (the JO part). A POJO is (http://c2.com/cgi/wiki?PlainOldJavaObject
) "a normal Java object that is not a JavaBean, an EntityBean, a SessionBean, etc." So, by definition, a POJO is an object which doesn't conform to some (official?) specification or framework. Right? If that's true, then the term "POJO persistence specification" is somewhat of an oxymoron. Is that what you mean? If so, then maybe you're right. Maybe they did choose a poor name. Maybe they should have chosen a name which more adequately reflects what they're trying to convey which is that the persistence specification is "transparent" or "non-intrusive" and can be applied to any object. Even those claims are a bit subject, though.
I don't so much mind the Serializable requirement for objects that need to be passed remotely, as that's just the way it's done in Java. Nor do I mind the getter/setter naming convention, as there are many very useful frameworks out there (Commons BeanUtils comes to mind) that rely upon those naming conventions. However, the code annotation requirement (is it a requirement or can you persist third-party objects for which you have no source also?) is somewhat intrusive, in that you do actually have to change source code to insert annotations into a class (not to mention you have to upgrade to JDK 5). The member visibility restrictions (no final methods) are also quite restrictive, but I think they are a bit more palatable. What did you mean by "naming conventions" besides the getters/setters? I'm not saying there are no other restrictions like that, but I just didn't see any that jumped out at me while skimming the specification.
All in all, I do like persistence frameworks. I use Hibernate a lot. I even use XDoclet to generate my mapping files for me, so I'm somewhat a hypocrite about the annotation stuff. However, Hibernate does allow me to write them by hand if I want to. I do not share your view of "Persistence is Futile" (although I applaud its originality). I do, however, think I might agree with you that maybe they should change their "pet name" for this specification (the spec doesn't mention POJO anywhere) so as to not bastardize (or hijack) the meaning of the term POJO. I still don't think that it's the intention to alter what connotations the term POJO brings about, but maybe they might have been a bit hasty when using the term to describe this specification. In the purest sense of the word, as the original person who coined it intended, the objects described by this specification are not POJOs.