I usually treat Bash as a lower level language.
I avoid it when the same thing can be done with Nix/Nixpkgs machinery.

If I understood this correctly, this code tries to detect if the recipe is a file or a string.
If file, pick it as is.
If string, put the string contents into a file.

This is similar to postPatch hook from dwl:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/dw/dwl/package.nix#L78-L86

Hmm, the point is to support not using a derivation for recipe, as @adisbladis said in #330589 (comment).

So writing some bash is inevitable, I guess.

Hum, I do not know if this is the idea from adisbladis in that comment.

To me it looked like "the user (whether human or machine) should have the option to pass a file or a string" (and, of course, files can be generated by derivations too).

In this sense the example I provided looks cleaner and reduces the Bash code to a couple lines.
The Nix code receives the recipe in whatever format, and returns a file containing the recipe, so that the Bash code does nothing besides linking that file.

The only advantage of using the Bash code I can think is maybe some micro optimization.

I think the goal to avoid using a derivation for recipe. So in your example, this should be avoided.

It does make any difference? In the end we have a string converted to a file, whether if it is made by Bash or Nix+Nixpkgs.
(Further, if I remember correctly, a raw file is converted to a derivation too.)

I think the Nix code is slightly more readable.
On the other hand, if the Bash code is more efficient (maybe because Nix is slower, or some context in the background has a hidden penalty), then it would be something positive.

I guess not using a derivation increases performances a bit. To benchmark that, someone needs to make generated melpa packages use recipe content string first.