Hmm... That's really confusing. If image exported in Linear gamma and with embedded Linear ICC profile, isn't it should look correct
It does look correct for what it is. Let me try to reduce the confusion
Internally, the scene is represented as a 0-Infinity floating point range (practically it's bound, of course); by convention, the values of a properly exposed scene land according to the diffuse reflectance scale, e.g., middle gray (18%) lands on 0.18, 90% white lands on 0.9, and so on. Everything above 1.0 is highlights/HDR (clouds, sun, specular reflections, emissive light sources, etc.). On export, you choose how much of the highlight headroom to preserve, e.g., the default "4 stops above white" means you sample the 0-16 float32 range, normalise it to 0-1, and quantize it to, e.g., 16-bit integer range. So 0.0 lands at code 0, 16.0 (max) at 65535, and scene white (1.0) at 4096.
ICC profile just declares that the encoding is linear and the color primaries are such and such. A color-managed viewer/editor will then apply the forward color matrix and the appropriate OETF (e.g., sRGB or gamma-based encoding) and send it to the display pipeline, which applies the inverse (EOTF) to derive the actual (linear again) brightness levels it needs its physical pixels to achieve.
So all this means that the relationship between different levels of brightness on your display (assuming it's properly calibrated) matches the one in the original scene, e.g., if a patch A is twice as bright as patch B in the scene, the image pixels representing patch A will have 2x values of patch B pixels and your display showing patch A will light twice as brightly as patch B. It says nothing about how bright they actually have to be in absolute terms, just that the relationship is preserved.
So if you're looking at the entire range from 0 to 16 as-is on an SDR display, it will have to look dark (because your brightest display pixels represent a value 16x brighter than the scene white).
That's sort of why we don't usually look at linear images on SDR display; they're meant to be tone-mapped before they look nice
same as in browser Density preview
Density preview shows, as the name suggests, density
Which is logarithmic, not linear.
Maybe you use some algorithm for DNG that expect additional transformation using metadata in Adobe apps
Lightroom always shows you an already tone-mapped view, not raw values. Again, because why would you want to look at those directly? DNG has the metadata that tells Lightroom where the scene white actually is in the linear range, so the image looks well-exposed after tone-mapping.
source of banding in Histogram
That has nothing to do with the data. The sawtooth pattern you see is just a result of the math behind how histograms are made (uniformly spaced accumulation bins vs non-uniform input). Even if you take a perfect greyscale gradient, you'll still see the same pattern (and those simulated scans you're using aren't perfect gradients to start with). Here's a perfect gamma 2.2 greyscale ramp in Lightroom, for example.
