The ( IF ... THEN ... ELSE ... ) embedded in the WHERE clause is treated as a function.
In general it is preferable to avoid having function calls in a WHERE clause. Some, but not all, can be resolved on the server side. (User-defined functions and CAN-DO() are two examples that must be evaluated on the client.)
In your case I don't know that the IF is always true. If specMode is true then it is but if it is false the ELSE portion is evaluated and I can't know how that works out without looking at the data. So it would not necessarily be correct to replace it as you suggest.
If specMode is always true then, yes, replacing it as you suggest (both versions) will work.
From an efficiency point of view the use of the IF function eliminates the ability to bracket on the loan.spec field. If loan.date and loan.type are leading components of an index then they will be used to bracket. If loan.spec is also an index component it cannot, however, be used to improve the selection and the whole subset of records carved out by the other criteria will need to be examined individually.
I think that the code you are showing is probably being used to provide a "clever" option of showing either ALL records with date and type, or just a subset of date, type and spec. This might have been an attractive (but hard to read and inefficient) approach back in the old days. It would have allowed a single block of code to handle whatever is inside the loop body.
In today's world you don't need to do that. You would just write a dynamic query and populate a proper WHERE clause as a string that you then use QUERY-PREPARE on. That way if loan.spec is part of an index it can be used to help support the query and those cases will run much faster.