🚀 go-pugleaf

You seem to be assuming that, upon conversion to ProPhoto RGB, and/or subsequent to an image edit, certain colors in the image will drift into the "imaginary" region of ProPhoto RGB and be forever lost, with dire consequences -- or "disastrous", or "ugly".

In my years as an imaging professional using fully color-managed late-binding workflows I have detected no ProPhoto RGB "misbehavior" that was so glaring that I or others noticed it.

Seems to me that your argument is informed more by Dan Margulis' own prejudices against wide-gamut RGB color spaces than by arguments whose validity I can recognize based on my own experience. I suggest that you take his "advice" with a generous grain of salt.

      RIMM can be considered as an RGB space between camera RAW and the ICC
      Profile Connection Space




You can say that RIMM is the intermediator between the input scene's Raw data and the ROMM/ProPhoto RGB space that one can use for output, storage and manipulation -- but it should not be implied that Raw itself is a color space.

A color space has primaries and tonal curves. Camera Raw is simply a mathematical construct for input that needs to be translated into colors usable for output. It has no defined primaries or tonal curves.

      The authors are comparing their good result with the bad result for some
      other nameless wide gamut space. Now, for what is it good - useful strategies
      ten years ago ? For nothing, because nowadays and in future manipulations
      of this type are done professionally in Lab.




That is, by Mr. Margulis and those who get lost along with him in his "canyons". Not by me or other professionals that I share knowledge with. You wish to sound as if your advice is based on widespread practice, but it's actually free advertising for someone who I have to admit is a sharp self-marketer who, on his way to dubious fame, also manages to dupe intelligent people.

      Surprisingly, the oversize of pRGB, as defined by the gamut triangle in
      xy, or by a volume in Lab, was not chosen so large because of the necessary
      gamut size but because of the hue robustness against 'luminosity' changes.




Not true. The gamut size was very much a core consideration in creating RIMM/ROMM, not secondary to what you call "hue robustness". It was a matter of finding the best compromise, among other factors, between quantization due to "out-of-locus" primaries, efficient encoding, gamut large enough to encompass real-world surface colors and suitability for storage and color/tonal manipulation.

To quote:

      ROMM RGB was designed to provide a large enough color gamut to encompass
      most common output devices, while simultaneously satisfying a number of
      other important criteria [described on page 2 of the PDF document cited
      below]. [...] Increasing the gamut can only be achieved by trading off
      against correspondingly larger quantization errors. If the primaries are
      chosen to include the maximum possible chromaticity gamut (i.e., the entire
      area within the spectrum locus), a significant fraction of the color space
      would correspond to imaginary colors located outside that region. Therefore,
      in any encoding using such a color space, there would be �wasted� code
      values that would never be used in practice. This would lead to larger
      quantization errors in the usable part of the color space than would be
      obtained with different primaries defining a smaller chromaticity gamut.
      It is therefore desirable to choose primaries with a gamut that is �big
      enough� but not �too big.� [...] [T]he primaries selected for RIMM/ROMM
      RGB [...] encompass the gamut of real world surface colors, without devoting
      a lot of space to non-realizable colors outside the spectrum locus. "Reference
      Input/Output Medium Metric RGB Color Encodings (RIMM/ROMM RGB)"
      <http://www.colour.org/tc8-05/Docs/colorspace/PICS2000_RIMM-ROMM.pdf>