All flash memory devices, from tablets to phones to smart watches, to SSDs and even the SDcards in cameras and USB thumb drives use NVRAM technology. The difference is in the architecture of the NVRAM, and in how the operating system mounts the filesystem on whatever storage medium.
For Android tablets and phones, the NVRAM technology is eMMC based. The data I can find on this technology suggests between 3k to 10k write cycles. Unfortunately, none of what I have found so far is definitive, as Wikipedia is blank on this technology's write cycles. All other places that I've looked at just happened to be various forums, so hardly what I would call a reliable source.
For comparison's sake, other NVRAM technology such as SSDs which use NAND or NOR technology, the write cycles are between 10k and 30k.
Now, regarding the OS's choice of how to mount the filesystem....
I can't speak for how Apple does it, but for Android, the chip is partitioned out like a hard drive would be. You have an OS partition, and a data partition, along with several other proprietary partitions depending on the device manufacturer. The real root partition lives inside the bootloader, which is bundled as a compressed file (jffs2, cramfs, etc) together with the kernel, so that when the device's stage 1 boot is complete (the manufacturer's logo screen usually), then the kernel booted and the root partition is simultaneously mounted as a ram disk.
As the OS boots up, it mounts the primary partition's filesystem (/system, which is jffs2 on devices before Android 4.0 and ext2/3/4 on devices since Android 4.0, and xfs on the latest devices) as read-only so that no data can be written to it. This can, of course, be worked around by so-called "rooting" of your device, which gives you access as the superuser, and allows you to remount the partition as read/write. Your "user" data is written to a different partition on the chip (/data, which follows the same convention as above based on the Android version).
With more and more phones ditching the sdcard slot, you might think that you'll hit the write cap sooner because all of your data is now being saved to the eMMC storage instead of the sdcard. Fortunately, most filesystems detect a failed write to a given area of storage. If a write fails, then the data is silently saved to a new area of the storage, and the bad area (known as a bad block) is cordoned off by the filesystem driver so that data is no longer written there in the future. If a read fails, then the data is marked as corrupt and either the user is told to run a filesystem check or check disk, or the device automatically checks the filesystem during the next boot.
As a matter of fact, Google has a patent for automatically detecting and handling bad blocks.
https://www.google.com/patents/US7690031
To get more to the point, your question "how did this suddenly become practical?" is not the right question to be asking. Rather, it was never impractical, in the first place. It was strongly advised against to install the OS (Windows) on an SSD (presumably) because of the number of writes that OS does to the disk.
For example, the registry receives literally hundreds of reads and writes per second, which can be seen with the Microsoft/SysInternals tool Regmon (https://technet.microsoft.com/en-us/sysinternals/regmon.aspx)
Installing the (Windows) OS was advised against on first generation SSD drives because, with the lack of wear leveling, the data written to the registry every second likely eventually caught up to the early adopters and resulted in unbootable systems due to registry corruption.
With tablets and phones, and pretty much any other embedded device, there is no registry (Windows Embedded devices being exceptions of course) and thus, there is no worry of data constantly being written to the same parts of the flash medium.
For Windows Embedded devices, such as many of the kiosks (including Walmart and Kroger self checkout kiosks) out in the public -- you know, the ones where you may see a random BSOD from time to time -- there is not a whole lot of configuration that can be done, as they are pre-designed with configurations that are intended to never change. The only time changes take place are before the chip is written in most cases. Anything that needs to be saved (such as your payment to the grocery store) is done over the network to the store's databases on a server.