Session has published a response:
https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture
They again confirm that they have intentionally reduced the security from 256-bit to 128-bit, and intentionally removed perfect forward secrecy. What is new to me is that the reason for reducing the security is to make the seed phrases shorter and easier to remember, that is, user convenience. About perfect forward secrecy they just say the same as before, it is not suitable for the decentralized onion network layer, so they decided to remove it. In both cases, they reduced security compared to the Signal protocol for seemingly convenience reasons.
They claim the security actually is 128-bit and not 64-bit as claimed by the security expert. I do not understand any of the technical details discussed by either party, but according to the rule of thumb I have been taught, elliptic curve cryptography provides half the security in bits compared to the size of the key used. So to have 128-bit security one should have a 256-bit key, that is, a key with 256-bits of entropy, not 128-bits of entropy as Session is doing. I guess an actual cryptography expert have to rule whether what Session is doing is actually secure, but I wished I would have got a better explanation from them why they choose to have 128-bits of entropy other than that "it makes the seed phrase shorter and easier to remember".
They also claim the security expert misread the code about onion network layer not providing any effective encryption at all. There are two methods called encrypt(), one taking the key as a ByteArray, the other taking the key as a String. The encryption using ECDH supplies the key as a String, according to Session. After reading their code, I agree, the security expert has read the wrong encrypt() method. What I can see, the EC public keys used in both code paths pointed out by the security expert are of the type String, always. And the encrypt() that takes a String seem to do ECDH session key derivation in the standard way, including with a simplified HKDF-like step. So it looks correctly implemented to me. One can maybe still argue they shouldn't have two encrypt() methods where one take a ByteArray and the other a String, since neither ByteArray nor String are very hard types. They should either had separate method names, or more clearly defined types such as types named something like SymmetricKey or ECPublicKey, to avoid all risk of the wrong encrypt() method being selected.
In short, Session developers are rejecting all claims of new not-previously-known vulnerabilities or weaknesses in the protocol, but confirm all the previously known weaknesses, that is, only 128-bit security and no forward secrecy, and again say they won't fix that and that it is intentional. They insist the protocol is secure up to 128-bits of security, which if true absolutely is adequate today. But they admit they have deviated from security standards in multiple ways.