These are some comments I received from a developer:
- Some of the newer "function functions" that were introduced since we switched to the newer methods don't support the older syntax. For example, the older BVP solver bvp4c allows the trailing parameters syntax, while the newer BVP solver bvp5c does not. Thus switching from one solver to another will work if you use the anonymous or nested function approach (well, at least back to release R14 when we introduced anonymous and nested functions) but may not if you use the trailing parameters syntax. Similarly, quad supports trailing parameters while quadgk does not. This was a deliberate decision based on the experiences we've had with the two other considerations below.
- If you use the trailing parameters syntax for a function function that receives (either directly or via the options structure) multiple functions, all those functions must accept all the trailing parameters, even if they don't use any of them. So if you call ode45 with an ODE function and an options structure that sets the OutputFcn, Jacobian, Events and Mass options to be function handles and each of those takes a distinct additional parameter, all five functions will need to accept all five additional parameters.
- If you want to call quad with a function handle and limits of integration (just the required inputs) and an additional parameter you will need to specify empty arrays for the tol and trace inputs. Failing to do so will result in MATLAB using one of your additional parameters as the tolerance or trace value and passing one too few additional parameters into your function handle. This causes a lot of confusion for users, somewhat for quad, but even more for one of the Optimization Toolbox "function functions": fmincon. fmincon has only four required inputs but the additional parameters don't start until the eleventh input. [fun, x0, A, b are required; Aeq, beq, lb, ub, nonlcon, options are optional.] Missing a [] and having fmincon error while trying to interpret your first additional parameter as an options structure happens fairly frequently.
- Personally, I like having the additional parameters included right next to (indeed, inside) the function that uses them as opposed to at the end of a (potentially long; see fmincon) function call. In my opinion, the locality helps readability.