Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
Recent-ish project: holding on to multi-year old legacy data that was simply bad/broken (but was assumed to be good because it was barely used/examined), then requiring every single new feature to work flawlessly with broken data, ensuring that legacy customers 'never' hit an error (when 95% of them have not logged in in years). That's a candidate for 'rewrite from ground up' - you can keep an old system going in maintenance mode, build the archetypal "version 2", then decide if/when/how to migrate old data over...
Knowing that you can 'evolve' a system towards improvements and knowing when you should do that is another sign. Something may be technically possible, but the time/effort/cost can outweigh whatever benefits there may be.