Could you use cmakeFlags = [ "-DINCLUDE_INSTALL_DIR=${placeholder "dev"}/include" ] instead of preConfigure?

I wasn't aware that the placeholder builtin had been added.
The nice thing about using outputDev is that it's valid regardless of whether or not a separate dev output exists.

I agree, this should definitely use outputDev, otherwise it may silently fail.

This package has control over the outputs it provides. And even if someone used marble.overrideAttrs (super: { outputs = null; }), removing dev output will definitely not fail silently.

I just want to point out that outputs can't be null or empty.
marble.overrideAttrs (oldAttrs: { outputs = [ "out" ]; }) fails when trying to install to the temporary string provided by placeholder "dev". In order to avoid it you would have to use: marble.overrideAttrs (oldAttrs: { outputs = [ "out" ]; cmakeFlags = []; })
I really don't see the advantage of that method .

Placeholder variant is much more concise. Why would anyone in their right mind remove dev output?

Concision is not a virtue above correctness.

Perhaps we could use placeholder with assert (lib.elem "dev" outputs).

It will be asserted by virtue of trying to install into the dev output. When the output does not exist, the installation will fail.

I'm not saying it's a common thing but there is precedent for it in-tree:
untrunc overrides libav_12 removing dev
systemd-cryptsetup-generator overrides systemd removing dev

Failing during install, when we could fail during evaluation, is disrespectful to our users. Not failing is preferable to both.

At the moment, I am maintainer-by-default of this package. Because I'm responsible for providing support for it (what support I can), I would prefer it not fail if possible. If either of you or anyone else wants to take over maintenance of this package, I will defer entirely to that person.