It's because these methods rely on the transaction log, which itself is only reliable in the full recovery model. Please read the following page in its entirety, as there are several hints there about the differences between simple and full recovery, and why full is so important for DR:
If you want to use simple recovery, then you'll only be able to achieve DR by taking full and differential backups. In which case you lose point-in-time recovery.
In some cases that's ok, but we have no idea what your RPO/RTO is, nor do we know your tolerance for data loss, disk space used by backups, etc. You can stay in simple recovery mode and have relatively reliable RPO, if you want to take a full or diff backup every minute all day long. Log backups tend to be a quicker, easier and more reliable way to achieve optimal RPO, and I suspect most people are using full recovery already for that very reason. So the requirement of AlwaysOn and other technologies that take advantage of this model is not usually much of a stumbling block or head-scratcher. But it is a hard requirement, and the reasons are rather irrelevant, but you can probably assume that one of the most basic reasons is that in simple recovery (or even bulk-logged) you can actually lose transactions that won't ever get shipped to secondaries, leaving it in an inconsistent state.
Everything is a trade-off. My feeling is that a lot of people prefer simple recovery because there are fewer issues they have to deal with regarding the transaction log (it's a myth that these issues dwindle to 0, however). It's like a lot of things - that trade-off works fabulous until you actually experience a disk failure, human error or other outage that requires you to revert to backups. In full recovery you are kind of forced to manage your logs proactively (otherwise they will consume your disks), and you can always get to a specific point in time in the event of a failure. In simple this seems to me to be a very easy gateway to not paying attention to backups at all. That's just an opinion, and not a technical fact, but it is based on a very large sample size.