Builtin MEX functions are handcoded and have been optimized/worked on for years; the Coder is machine-generated code that is portable and generic; it's not terribly surprising it isn't as efficient.
The optimizations object basically turns on specific compiler flags, but those do nothing to markedly affect the code generator itself that converts the MATLAB m-code files to C.
What, if anything, you could do to cause the Coder to generate better, faster code would pretty-much be dependent upon whether you could find ways to improve the m-file code itself to produce a better translation -- but there are no real rules for there other than the generic guidelines in the documentation about optimization that I'm sure you'll have already looked at.
While sometimes one can make things markedly faster by converting m-files to mex; it isn't always the case and when it is possible it generally is the result of knowing how to write efficient C code that bypasses higher-level MATLAB constructs, not just that C is faster than MATLAB. That used to be true, but no longer with all the advances in the JIT compiler; if one is doing mostly numeric operations and the code is vectorized, the base MATLAB m-file code may well run essentially just as fast as optimized C code--it does, after all, boil down to eventually calling the highly-optimized BLAS or LAPACK libraries for basic operations and unless you have such code and help the Coder along in calling the standalone libraries, it will generate base transportable C code instead.
