Of course, you can use whatever you think is more suitable for you

.
But there are some things I'd like to add to your notes.
The advantage(s) of having it in a REXX DLL is:
- The DLL is faster than the interpreted code
I don't think so because the DLL is basically doing nothing than forwarding parameters.
- As you noted, the same DLL can be used to provide added functionality
- It simplifies the base code, since unlike C, you cannot (easily) have function calls to external REXX functions while maintaining full capabilities
This is not correct. You can have REXX functions externally. Just put the function code into a separate REXX file and call it exactly as the function name. If the function you want to have externally is called imgReSize, simply name the file imgResize.cmd and put the code into it but skip the function declaration and use exit() instead of return. The REXX interpreter will automatically call the the function when it is not found in the active REXX file. Have a look at the attached example. The package contains both variants.
- Since GBM is being regularly updated, it means that, with no revisions to the REXX code for new formats, simply replacing the DLL with the newest version "updates" the REXX program's capabilities (for instance, being able to determine image sizes of new or variant image formats)
In principle this is correct but in the special case that we discuss here it is different. The GBM code for scaling is not part of gbm.dll but part of either gbmrx.dll or jep's dll. This means that if a fix is done for the scaler,both dlls needs to be updated. If the function would be coded in REXX using gbmrx.dll, you would automatically get the fix because gbmrx.dll is always part of the GBM package.
- It means that (for instance in my case, where we use a lot of web scripts), one does not have to add a whole section of code to each and every REXX cgi script just to read image information... instead, I would load the DLL once on server startup, and then call the functions in it.
Have a look at the attached example on how this can be done.
- It increases cgi performance for more reasons than the fact that a C DLL is faster than interpreted code, such as the simple fact that the web server's cgi engine has a bunch less code to load to execute the same tasks (since the DLL is already loaded into memory, making the DLL call method not need to have a few dozen copies loaded, nor require the web server's cgi engine to reload that section of code for every thread it is running that uses that code)
If the function really has many things to do, you're right. But in this case you won't probably notice any difference. In case you don't know yet, the OS/2 REXX interpreter stores a tokenized version of the program in the extended attributes of the script. Thus running the script again is very fast. This is especially important for externally located functions.
Thus to clarify, my point is: each method has enticing reasons why some would prefer them. I personally prefer jep's method as most of the coding I do is either (a) for web cgi (and his method is more compact, faster, and easier to code with) and/or (b) I like writing wrapper functions for various things to simplify calling stuff from anywhere - which I find far easier with functions set up all in one DLL and/or (c) as my web server gets quite a decent amount of traffic, I find that 20 or 50 or 100 lines of extra code does indeed impact performance, disk usage, etc (and I like minimizing disk usage as much as possible since SCSI disk drives are kinda expensive).
Well, if reducing disk accesses is your optimization goal, you should better use a RAM disk or prevent creating temporary files. This is also the big advantage of the gbmrx API design. All transformations on the bitmap can be sequentially done in memory without writing intermediate files.
For standalone apps that just need to query image parameters, having everything in REXX may be better, easier to implement, and would save memory since the code is only loaded with the app, then can be unloaded when the app exits (unlike my scenario, where the REXX DLL needs to be loaded at server start and NEVER unloaded).
The same mechanism also works with the externally located REXX function. In the attached example (runme_separate.cmd) the dll is loaded and only unloaded at the end of the program.
I hope the examples and the hints are helpful.

eville