DETS overwrites its data files on updates and if power is removed abruptly, then on the next boot, DETS may have to repair the file. There's some information about this at http://erlang.org/doc/man/dets.html near the warning about using CTRL+C. It can't always fix a corrupted file and you lose everything in the file. That's the issue. For many embedded devices, ensuring that the device is always gracefully shutdown is not possible so then you would end up writing code to deal with lost DETs tables. If there's a parameter that doesn't have a good default or can't be automatically restored, then the device stops working. If you have access to the device to fix the files manually or the DETs tables don't contain anything critical, then using DETs seems fine.
You may also be interested in how DETS corruption impacted a commandline history implementation: https://github.com/ferd/erlang-history#how-do-you-store-history. Back when I first saw the note, it surprised me, but it's the same issue.
As for SDCard wear levelling (or lack of), that can be a problem too. I've mainly seen it in devices that log at high verbosity or save video, but if you're not hammering the SDCard, I think that you should be fine. There's a chance that you'll run into a flakey SDCard, but things seem better now than they did 5 years ago for me. (anecdotally, of course)
Also, everyone I know has more than one file for saving data on their production devices. Critical configuration and provisioning data is stored in separate files or separate disk partitions to isolate issues with the main database. They do this even if their main database has journalling, etc. that recovers from crashes and poweroffs well. It may be overkill, but some devices are so hard to manually access that it seems worth it just in case.
Hope this helps,