Contracts evaluate signed transactions from users. They don't evaluate how the user composed the transaction or signed it. From a human perspective, it is helpful if a UI guides the user, composes the transaction and offers it for signing but, typically, this is of no concern to the contract.
Contracts need to guard their internal integrity regardless of what any UI sends them. It is always an indicator that a design defect probably exists if the contract's internal security relies on restricting the users to a certain interface. This is a variant of strategies that try to prevent other contracts from using the contract, which is similarly almost always an error.
If the contract is indifferent to the origin of a valid transaction and it rejects everything that isn't allowed, then it shouldn't matter which interface is used or the nature of the user. That approach protects the system from possible developer error in future front-ends. It enables novel interactions with other contracts (composition) or even the creation of UIs and APIs by third parties which is usually a sign of traction.
Hope it helps.