A feature of Excel as an example of End User Computing is that it allows inexperienced end users to generate very bad code exceptionally quickly. The major plus is that it [sometimes] gets their job done without even needing to recognise the solution they generate as code.
I would assess an Excel solution in exactly the same way as I would code and, left to itself, both macro recorder and spreadsheet formulas produce highly suspect code. How could it be otherwise; Excel is building a record of your actions, not your intentions. It has no knowledge of your intentions or of the business domain to which you will apply the solution, so normal coding criterial such as: 'Have the variables been declared?'; 'Is this reference in bounds?'; inevitably fail [unless the developer has adopted highly non-standard strategies such as declaring names and using multi-cell array formulas in place of 'fill-down'].
Both worksheet formula solution and macro-recorder solutions can be made more formal and structured (in the latter case including elements of OOP) but that does run counter to the original intention of spreadsheeting. Equally some scripting and even compiled languages allow the programmer to work intuitively with no pre-defined variables [the user could introduce variable names (A1, A2, A3 ,...) sequentially and on the fly]. Just as the spreadsheet supports just about any layout, it is possible to achieve much the same effect in code through the generous and liberal use of GOTO.
I contend that the issue of whether Excel is code [or whether it is Turin complete] is something of a moot point; the resulting workbooks need to be assessed and audited as code.