I expect to be able to go in and out of my door. That's what doors are for. Apple doesn't even give you a door. You have to break your way through the wall. Then there's a hole there. That's why Apple products are only sufficient for sheep. They don't break down walls, they just wander through holes.
It's worth pointing out that if you root your Android device you're doing the same thing, breaking through a wall. That's fine if it's what you want to do, but you are giving something up in terms of security.
As a member of the Android security team, I'm involved in lots of discussions about lots of different threat models and attack vectors, and while we do think about trying to maintain security on rooted devices, I'd say that 90% of the time we end up deciding that we just can't, so "device is running an official image[*] and is not rooted" becomes a foundational assumption of the analysis.
This isn't because rooting is inherently bad, or because we're trying to control user's devices, but because it's impossible to reason about security in a vacuum. You have to know what you can depend on. For example, we might argue that apps can't break out of their sandbox in a particular way because the information they need to do it is managed by a particular system daemon which validates access in a particular way... but in a rooted device that daemon may be modified, or simply bypassed. We just can't know that stuff is still working the way it's intended to. Some members of the modding community do an outstanding job of adding flexibility without breaking the security model, but many others don't.
Ideally, devices should provide enough native flexibility to allow users to achieve what they want while staying entirely within the normal mode of operation. In the case of Android that means staying within Google's "walled garden": install apps only from the play store, keep Verify Apps enabled (and follow its recommendations), don't root, definitely don't disable SELinux, etc. Where that ideal fails, and users want to do stuff that can't be done in the garden, they should have the option of stepping out of it, and they should be able to do so in a progressive way, not all-or-none... but each step they take increases the probability that they'll change something that violates a security assumption and thereby increases their risk of compromise.
I suspect that Apple security engineers even more strongly assume that devices are not jailbroken. That's just a guess, but it's consistent with the general philosophy of iOS and, if correct, it means that jailbreakers have even less expectation of security. iOS users also live in a software monoculture, which exacerbates the risk. (Android users get security benefits from ecosystem diversity, though there are obvious costs to that diversity as well. Including the update problem.)
[*] Note that given the state of updates in the Android ecosystem, we often don't assume that the device is running an up to date system image. From our perspective that's often easier to work with than a rooted device because at least we know how it behaves and can look at trying to mitigate risks at other layers. We're also working on the update situation, but that's hard given the nature of the ecosystem.