I’m assuming you are using the darktable built-in sRGB profile. This is a bog-standard matrix profile. It doesn’t have a perceptual intent table. I suspect that if you export your file using all four “intents”, you’ll produce four identical files.
Cambridge in Colour is a wonderful website and the referenced article is excellent. However, the output profiles that he’s talking about are Look-Up Table printer or CMYK profiles with four intent tables. The sRGB profile is a matrix profile and doesn’t have any intent tables at all. Without intent tables, you will never have perceptual intent or saturation intent as actual choices, instead you’ll get relative colorimetric intent.
Regarding absolute vs relative colorimetric intent, yes, matrix profiles in theory support both of these intents. But in a V4 workflow such as what darktable uses, converting between matrix RGB working spaces uses relative colorimetric intent even if you ask for absolute colorimetric intent. This was a major point of disagreement in the change from V2 to V4 ICC profile specifications.
Figure 4 in this article shows what an actual absolute colorimetric intent conversion in a V2 workflow looks like:
In either case, V2 or V4, and relative or absolute colorimetric, the conversion to sRGB does clip out of gamut colors. There’s no gamut compression even if you choose perceptual intent, because the sRGB matrix profile (and AdobeRGB, ProPhotoRGB and all other standard RGB working space profiles) are all matrix profiles, which means no tables, which means the only available intents are relative and absolute colorimetric.
And in a V4 workflow, unless your image editor provides a special chromatic adaptation slider (I don’t think darktable does this, GIMP doesn’t, Krita does but I’ve never used it), asking for absolute colorimetric intent when converting to an RGB matrix working space profile actually gives you relative colorimetric intent. Asking for perceptual gives you relative colorimetric. And asking for saturation also gives you relative colorimetric.
You might find this article helpful, though I’d recommend reading the Cambridge in Colour article first:
If you read the above article, I’m still trying to figure out what happens when the source profile has all four tables (this is mostly only relevant when converting for example from a printer profile back to an RGB matrix profile working space, or between two printer profiles), and I’ll update the article if I ever get this somewhat unusual (well, I think it’s probably an unusual thing to do) type of conversion figured out.
As far as sRGB being “weak” or having a small color gamut, yes, it really does have a small color gamut compared to colors that can be captured by today’s digital cameras, displayed on today’s wide gamut monitors, and printed using today’s high-end photographic printers. sRGB is particularly weak in blue-greens, greens, and yellow-greens, exactly the colors in the dragonfly image.
This article explores the question of which colors that can be captured by a digital camera are out of gamut with respect to the sRGB color gamut:
This tutorial has diagrams showing the relative size and shape of various ICC profiles your image might encounter along the way from camera to output:
AdobeRGB will probably easily hold all the colors in the dragonfly image (which is a very pretty photograph, I love the dragonfly’s blue, green, and orange-red colors in front of the out-of-focus background greens). But putting an AdobeRGB image on the web is risky - if your viewing audience is composed of photographers, hopefully most of them have calibrated and profiled monitors, and are using a properly color-managed browser. But for most people even today, color management is not well-implemented on their various viewing devices. So for posting images to the web, sRGB is still the safest choice.
Which as @paperdigits notes, leaves reduction of the saturation of the out of gamut colors before export, and/or allowing the out of gamut colors to simply clip, as the only viable solutions. Personally I try to bring colors back into gamut before exporting to sRGB. But for bright colors, if clipping doesn’t produce any visible artifacts then usually I just let the colors clip.