[Nexus 7 (2013) Q&A] sfhub:
I'll give you two examples in the past (not on Nexus) where such issues came up.

With some LG phones, the procedure to flash the phone radio required special communication between the update and the kernel through some proprietary commands relayed through special partitions, the custom ROMs on that platform did not handle those commands so after the flash you were left with the new rom and firmware but old phone radio. This mismatch led to the phone not booting.

On Samsung Galaxy 2, they had some issues with certain eMMC firmware commands causing data corruption. The original Gingerbread kernels did not use these advanced commands but they were enabled in the ICS kernel. If you did the upgrade using the Gingerbread-kernel based recovery, which is what would happen if you used stock, the upgrade would happen without issues saving you one round of exposure. If you did a future upgrade using the ICS-kernel based recovery, then you were exposed to the eMMC issue. Some custom recoveries already updated to the new ICS kernel so if you used them, you were exposed to the eMMC bug even with the initial ICS flash. It took us a long time to isolate what the problem was with the eMMC corruption and even longer for Samsung to acknowledge and fix it, even though we gave them the source code changes for the fix.

Anyway, my point is that what Google/manufacturer uses to test their updates is the stock recovery. If there are any issues with that pathway, they will try to fix it before releasing. They don't test with any of the custom recoveries so if problems arise, they will never know and they won't support it even if they did, unless it is some big generic issue.

Even with the stock recovery on this Nexus, you are getting eMMC corruption. You can see this in the posts where people with completely stock devices out of the box are failing the OTA integrity check for the 2nd update. At first I just thought they were glitches in the manufacturing process using some faulty image, but the files that were not matching MD5 were different on various units.

Also I've never seen so many system UIDs inconsistent and I just rebooted and got stuck on X complaints as on this platform.

The final nail came when I saw the various eMMC "stability" changes Google added for the JSS15Q release, including different mount options for volatile filesystems like /cache and /data and kernel changes in how it communicates with the hynix emmc part.

So IMO I wouldn't trust any recovery (stock or custom) based on a kernel prior to JSS15Q. I also wouldn't really trust boot images based on kernels prior to JSS15Q. In this case, even though we were exposed to the eMMC issues even on stock, we at least have a stock recovery with the new kernel after upgrading to JSS15Q, whereas we will need to wait for TWRP to upgrade to the new kernel for "safer" eMMC access.

I am sure the instances of eMMC corruption will be rare using the old kernel, just like the occurrence of people failing their OTA update sanity checks on pure stock are rare. The corruption may be happening in conjunction with the random reboots.

As always with these types of issues, if you aren't hit by them, you wonder why someone else is pointing it out because surely they are no big deal since you haven't been hit.

I don't go out and tell people not to use custom recoveries to flash their OTA updates and even tell people it will probably work fine. I just suggest if you don't want to be a guinea pig, let someone else do it first.