OK, let’s continue.

kind1059(kind13(kind14)) VS kind1059(kind1)

In the kind1059(kind13(kind14)) model, if the recipient discloses the encryption key, not only will the sender's messages be visible to everyone, but the recipient's own messages will also be visible to everyone. This is disadvantageous for the recipient and advantageous for the sender. In the kind1059(kind1) model, if the sender discloses the unencrypted kind1, everyone can see the messages sent by the sender. However, the sender can also proactively disclose the messages previously sent by the recipient. Furthermore, the sender can identify who disclosed the messages, which is a good thing. In both cases, the sender can determine who disclosed the messages.

Finally, regarding the issue of app bugs causing kind14 leaks, it would require extremely poor code quality for this to happen. If you must consider this risk, why not directly encrypt the content using NIP-44? Using kind4(kind4) would be simpler than kind1059(kind13(kind14)). Please note that the kind4 mentioned here uses NIP-44 encryption, not NIP-4 encryption. 

 I think you missed the point. Kind1059 (kind1) has a problem where the recipient can broadcast kind1 without exposing any keys. However, kind1059 (kind13 (kind14)) requires exposing the share key, right? And kind4 (kind4) leaks metadata and is not even within the scope of discussion.

Moreover, I don't think the leakage of kind14 requires poor code. Even very rigorous code can have bugs and be subject to hacker attacks. What we need to do is not to hope for no bugs or leaks, but to ensure security even in the event of a leak. 

 Outer kind4 from: random public key, inner kind4 from: sender ID. 

 But yes, NIP-17 is relatively complex, and the random time is also frustrating. It's a trade-off, but so far, this nip is still more suitable for nostr DM IMO.