You are using cpower, indicating you think th problem isSOCP representable. However, it is not or at least YALIP can not derive this automatically otherwise fmincon would not have been selected. As it is now, you get a very bad model combining socp representations but using fmincon (which isn't good as YALMIP has to hack around the fact that fmincon doesn't support socp cones natively)
When I run the model fmincon struggles massively. You shouldn't need 10000 iterations, that just tells you the model is bad. fmincon terminates due to iteration limit, and the final iterate is infeasible. The discrepancy between fmincon objective and actual objective is probably due to some effect that the objective contains terms that are modelled by epigraph representations and thus only are correct when the constraints actually are satisfied and the solution has run until they are tight, which isn't the case here
This constraint moves you outside the SOCP world
K>> L.*C.*(1/2*(cpower(beta_u + 1./f_u,2) - beta_u_ini.^2 - (1./f_u_ini).^2) - beta_u_ini.*(beta_u-beta_u_ini) + 1./f_u_ini.^3.*(1./f_u-1./f_u_ini))<=z
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| ID| Constraint| Coefficient range|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| #1| Element-wise inequality (sigmonial,derived) 10x1| 1.66e-19 to 420000000|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
K>>
You have to model the 1/f_u terms carefully using cpower operators and possibly new temporary variables, if you want to use an SOCP solver
Adding to the badness, this is just silly
K>> 1./f_u_ini.^3
ans =
1.0e-27 *
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000