It is not uncommon for a paper to state that the proposed design was not designed to protect against related key attacks. One reason for this is the over-powered nature of the attack against confidentiality: If the adversary already possesses the key, and can encrypt and decrypt at will, then one has to wonder how/why the adversary even stands to benefit from running an attack.
The open key model appears to go a step further, and assume that the adversary may have even chosen the key in question.
As far as confidentiality goes, there appears to be little point to defending against a known/chosen key attack. Doing so would likely require a more elaborate design, or at least more rounds, which will degrade performance in the "regular" use case to protect against an edge case situation that seems unlikely to occur in practice.
As to why a paper would explicitly mention such a thing: It is better to see "we made no attempt to protect against this class of attack" as opposed to not even mentioning the existence of the class of attacks. If the authors decline to mention related key attacks, it could be interpreted that they were not aware of them, as opposed to did not care to defend against them.
On the opposite side, there is one compelling reason to try and defend against known/chosen key attacks: If the cipher is to be used as a component of a hashing function, known/chosen key attacks become a relevant threat model. For example, this is mentioned briefly on page 9 of the proposal for simon/speck.
