Subjectively, I would say software is harder to get right, and therefore the lifetime cost in terms of faults, revisions, warranty claims and maintenance fixes is likely to be higher due to faulty software than due to faulty hardware.
I would say some reasons for this are that hardware design falls more readily into standard design patterns, application notes, and known best practices, and is more readily subject to design review, inspection and test verification.
Software, on the other hand, tends to be written or customized uniquely for each application, is often written by people who over-estimate their level of competence, and is harder to verify by inspection. Software is demonstrably easy to goof up and get wrong in subtle but critical ways.
As a pragmatic engineer I would therefore prefer hardware solutions, even though the perceived cost in terms of parts and manufacturing might seem to be higher.
I find that a fairly insulating and inaccurate assessment from someone who has probably never done any professional software development.
Software tends to follow established design patterns, architectures and procedures. Software is developed under various methodologies some stricter than others. Software can be design reviewed, version controlled, tested and verified by multiple teams and the end customer. Software can go through multiple release stages, often called alpha, beta, gamma or "Dev", "SIT", "UAT", "Production", "Fail Over", Release candidates, release versions, legacy versions. Today a lot of this is entirely automated. You can't produce a line of bad code without something in the build chain whining at you about it or out right rejecting it.
Often people use what is called a "Gated SDLC", so nothing can move from one stage to the next without a gate review, checklist and all parties signing off on it.
Like electronics it depends on what you are building as to how much you spend (time/money) on process, documentation, test and verification. If you are making a hobby project, it's usually, "Looks like it works, it works." If it's a critical safety system for an airliner then every single line of code will have potentially pages of documentation, justification, test matrix entries, unit tests, integration tests, system tests, static, dynamic code analysis results, performance test results etc.
If you find a bug in a production product you can often patch it, in many cases without even an RTB. Embedded software being a little more difficult to patch in the wild, but non-embedded it's standard practice and happens on your mobile phone daily without you even caring.
If you find a bug in your electronics it's a RTB and a rework or bin the 1000s of boards you have in stock and re-manufacture.
Also, if you design and implement your software once, you can ship it a hundred million times at virtually zero extra cost. There is virtually zero cost per instance.