The role of the .local/share directory comes from the GNOME/freedesktop guidelines:
These are the guidelines on how to write well behaved desktop apps on linux (and there are quite similar conventions on MacOS).
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the
$XDG_DATA_HOME base directory. The directories in
$XDG_DATA_DIRS should be seperated with a colon ‘:’.
$XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.
$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If
$XDG_DATA_HOME is either not set or empty, a default equal to
$HOME/.local/share should be used.
Now, according to RT documentation, the DCP profiles should exist under
Basically, these dcp profiles are considered application data, and RT would look for them in a correct location, if only partially. The guidelines says the app should look in both /usr/share/… and in ~/.local/share/… however RT does not honor the second possible location.
For a traditional build, with a binary compiled and deployed somewhere in the host filesystem, this limitation would not be a major issue since the significance AND content of /usr/share/$something would be the same for all binaries on the system, so if one put a file under
usr/share/rawtherapee/dcpprofiles/ as the RT documentation says here https://rawpedia.rawtherapee.com/How_to_create_DCP_color_profiles, any other app on the system would potentially be able to find it.
UNLESS the app is an AppImage, which rather resembles a container that has its own private root filesystem with its own private /usr/share/$something, so now the contents of that folder is only whatever was bundled there in the AppImage.
For these cases the guidelines referred initially says that the app data can reside in ~/.local/share too, not only on /usr/share - to allow the user to add application specific data in a location that is both accessible to the user, but is also within the reach of the application.
More to the point, RT DOES honor another section of the guideline, the one sayin where the config files reside:
$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If
$XDG_CONFIG_HOME is either not set or empty, a default equal to
$HOME/.config should be used.
Wherever relative to the paths in XDG_DATA_DIRS I would place a rawtherapee/dcpprofiles subdir with the correct dcp profiles within, the profiles are still not loaded, it may be possible that the path RT’s documentation tells about is just a hardcoded default, and not a derivation from a proper implementation of the freedesktop guidelines.