If the profile is declaring what you will produce, it’s legitimate to set a maxOccurs of 0, though setting mustSupport=false can convey the same thing (provided that you set it to true for all the elements you do produce). When declaring what you will accept, maxOccurs should only be constrained if it’s an error to send the element to your system and instances containing the element (or containing more than the maximum repetitions) will be rejected. As a rule, this is undesirable interoperability behavior as it forces systems to customize their interface to withold data rather than just sending what they know. It increases the likelihood they’ll have to code separate interfaces for different systems which increases costs. It’s far better as a receiver to just ignore data that you don’t need. If there are limitations on what repetitions you can support, try to figure out what the criteria are that will distinguish the repetitions you want from all of the other repetitions that might exist. If necessary, have an extension that distinguishes them. While customization might be required to populate the extension, at least a common interface can be used as other systems receiving the instance can just ignore the extension.
Legitimate cases for constraining maxOccurs are for things such as deceasedDate if it’s an error to send information on someone not living. It may also be legitimate if you’re one of those rare systems that are deemed to have “custody” of information that you don’t reject and aren’t free to ignore information you don’t care about - but make sure that’s truly the case before imposing the burden of customizing interfaces on your clients.