The big joke is the differences between these two methods are trivial: both generate a key from the epub's first UUID, Adobe uses a 16-bit key XORd over the first 1024 bytes and IDPF hashes the UUID to create a 20bit key XORd over the first 1040 bytes.
At its root, this issue dates back to the silly political squabbles that occurred a few years ago when the ePub standard was being formed. This has resulted in the present mess where there's a large installed base of ADE-compatible readers using one method of font mangling, and another large base consisting of one device (the iPad) which doesn't (or may use the IDPF method since Apple has recently started to allow font embedding). Nothing has changed in the ePub 3 standard, which makes me think the IDPF thinks they can win by rigidly sticking to their guns and sticking their heads in the sand.
If your licence obliges you to obfuscate the font in order to embed it then you'll need to prepare different versions. If you're mangling a font for a book to be sold on iTunes, then you'll need to follow the idpf specs (there's a script from pdurrant floating around on the forum that will do it for you). For everywhere else, the output from InDesign should be fine. I'm not entirely sure about B&N, but their system works with ADE DRM in general, so it should be fine.
As far as epubcheck goes, it only generates a warning when it finds an Adobe-mangled font, that doesn't mean the epub isn't valid, and whatever system interprets the results should be smart enough to recognise that.