(1) Leave it to developers to make sure that their code correctly handles different DPIs. This results in every app having to produce its own solution for some very difficult problems, such as those ridiculous_fish mentions elsewhere in the thread, or else look terrible on some devices. (Yes, some of this can be encapsulated in libraries, but you'll virtually always do some custom drawing that requires manual handling.)
(2) Virtualize the pixels, so that depending on the DPI of the screen you're displaying on, a "pixel" does not necessarily correspond to a single device pixel.
Generally what happens is that you try #1, realize that many or most developers screwed it up, and shift to #2.
See CSS "pixels" for an example of this phenomenon.
(3) Expose both pixels and dips. Both are first-class units in Android. The 2D drawing API works exclusively in pixels, but the layout commonly works in DIPs instead.
Developers then do their layouts in dips but custom 2D drawing in pixels. Or really most anything in code is using pixels, dips are largely contained in the XML layout files.
True, BUT you still have that problem on the 6+ with everything being scaled by 15%. In fact, the problem is vastly worse. Instead of the occasional line being 2px instead of 3px, you now have every line being blurry. And you can solve the 2px vs. 3px line thing quite easily by letting devs choose between specifying in pixels vs. points, which is what Android does. The problems you talk about are all problems that only exist if you exclusively work in points. They all go away when you can also use pixels.
And the density is not at all high enough to mask this. It's very visible as soon as you pick up the device, and the dividing lines in things like the calculator app are hilariously uneven and awful.