This is from a user/documentatio perspective, completely ignoring any reason on the implementation side. Stay with me.

The persist() operation on Session is not cascaded at flush time. This is somewhat unexpected from a users point of view and very difficult to explain and understand (you need excellent knowledge of flushing and cascading). Reason #1 for removal.

The persist() operation in general does not return a database identifier. This is surprising, as the JPA spec clearly requires a persistent instance to have a database identifier value. Since persist() makes instances persistent, it has to have the same semantics for assigning identifiers as save(). Hence, I expect that once this mismatch is resolved in the expert group, the persist() method will return a database identifier. Everything else doesn't make much sense, given the current specification and documentation. Conclusion is that persist() will have the same signature as save(). Reason #2 for removal.

To document persist() properly I need a reason for its existence. Right now I'm telling readers/users to ignore it on the Session API, because it only complicates the situation with no benefit.