No, we shouldn't. If you build a bridge to last 200 years, it will remain unchanged for 200 years.
What piece of software can you possibly imagine still be useful if it remains unchanged for 200 years? 50? 10? Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?
Most software becomes obsolete by the changing digital landscape within a year or two if it isn't updated to keep up with the times. That's a major difference compared to physical objects - the physical landscape doesn't change nearly as frequently. That said, we still don't build most physical objects to last 200 years except for the very largest of a projects - and we frequently demo small buidings to put up high rises as the city landscape changes.
Yes, tons. For example, the firmware for my car's electronic fuel injection (EFI). A lot of software can't easily be updated, or lasts far longer than originally intended.
Treating software development as solely an engineering discipline is, in my opinion, a mistake. That being said, the vast majority of software projects today would benefit greatly from that approach.
Engineering projects do not change frequently and radically. They can't afford to - but more importantly - they don't need to, certainly not at anywhere the pace of software.
A bridge may undergo some changes and facelifts over a 200-year period, but it's still basically the same bridge. But there isn't much software that could last even a fraction that long and not be completely obsolete (without most of it's code getting replaced). In the case of a bridge, the underlying geography isn't going anywhere. That's just not the case with software - even if the platform still exists, the rapid pace of technology means that the software will stop being of any practical use.
A piece of software needs to keep evolving, or it's dead. The same just isn't true of most 200-year engineering projects.