getDataValue reads the "data" for a device object. The Data section is at the bottom of the device page. You can read existing data or you can store new data there.
settings.settingName is where the settings/preferences values are stored so you can use them in the driver code. I think this only works in a driver, not an app.
I think deviceObj.getSetting does the same thing but it was created so you could get the settings values from within an app.
For me it is the visibility, the states are little easier to work with but they are at the top of the device page, but I try not to clutter than up too much because to me its ugly. Also the states are not available to apps.
The Data I see as more of a long term storage, but it does not take kindly to saving some data types directly (like a map). Data is available to apps through the device object.
I am sure there is some underlying difference in how the hub reads/writes to those as well. I found if you are reading/writing to the data a lot you can step on top of yourself due to multipole functions running at the same time. So I now am just keeping the data in a Field variable to work with in the driver, and writing it out to the data as a backup for when the hub is rebooted.
This won't quite work; you won't be able to call getSetting() on an arbitrary device (e.g., on a device you've selected) from within an app. The device.getSetting() example is literal in that it literally must be called on the device object itself (from within that same driver code), or app.getSetting() if it's an app.
Ultimately, getSetting() is just "convenience" for the above, i.e., these are all the same in the end, which I'll spell out since it may be helpful for the OP:
settings.mySetting
settings["mySetting"]
device.getSetting("mySetting") (or app....)
mySetting (a bit of magic; setting/input names are "elevated" to fields so you can just use them directly, too)
It's there. Things in "Device Object" or "InstalledApp Object" are available on the device and app objects, respectively, but this could probably be clarified. (And things in "Common Methods" are available as-is in either.)
Yes, "Preferences" is the user-facing term that users see in the UI. The internal data structure in which these selections are stored is called settings (as are all methods that relate to this in app or driver code).
This is a Groovy term, not a Hubitat term, and just means that the variable/name is scoped to your entire app or driver (i.e., available for use anywhere in your code). See: Field (groovy 2.4.9 API)