adding to mdp2021's interpretation:
> Boring here seems to mean "reliable and easily understandable"
Another way to think about this is to consider the context that the software is used in, from the perspectives of users, operators, managers. Users want the software to be reliable, support their current browser, help them do the task at hand, and not corrupt their messages / lose their rent payment / leak their credit card numbers. Operators want to get a good night's sleep without getting paged because the site has fallen over again, and when things go wrong, want to be able to draw on an existing body of technical knowledge (documentation, bug reports, known workarounds) from the community about the known failure modes and shortcomings of the technologies that are being used. Managers want it to be relatively easy and cheap to hire new people to maintain the software when the original designers and developers of the system quit for better jobs / retire / are promoted away, want the system to be relatively cheap to operate, and want the system to be relatively flexible and modifiable so it can be bent to accommodate new requirements.
> My peers are building projects with short lifespans to get into the industry, which works to get a job, but feels like starting a bad habit.
Your peers are pragmatic. When I interview people for software engineering roles, I am mainly looking for problem solving skills, some fluency with basic data structures, ability to translate idea for a solution into simple working algorithmic code. We also really want capable and experienced engineers who know how to build and operate real systems, but do not expect grads to have any such experience -- this can be learned over time on the job once someone is working in industry, especially when supervised by senior engineers. Ability with the basics & potential to learn and become a lot more valuable gets you in the door as a junior.
A (the?) classic talk on the subject of boring technology is Dan McKinley's http://boringtechnology.club/
Another interesting read is Nygard's book "Release It!" about designing and building reliable systems, although it might be hard to understand the importance of some of these topics without first spending a few years in an organisation maintaining and operating systems and services that need to be available. https://pragprog.com/titles/mnee2/release-it-second-edition/
In terms of getting better at this without working in industry, perhaps one way could be to identify an existing open project that is relatively old and regarded as being well-engineered, stable and boring, and try to figure out how you can contribute to it.
Another way to build intuition about the importance of boring software is to gain experience maintaining and operating systems. E.g. set up your own services that run 24/7 providing value to yourself and others, then figure out what it takes to keep those services running enough of the time. Do this for enough years, every now again again some surprising failure mode will occur, and you may gain wisdom while trying to fix it or prevent it from ever reoccurring. I've personally written many useless short-term toy software projects to explore different ideas, but the hobby project that provided the best lessons in terms of building reliable software is a project that is actually continually useful to me (as a user, not as a hobbyist) so I am willing to invest ongoing time and energy operating and maintaining the software (web application hosted at home) -- over the years you need to deal with: operating system upgrades, database version upgrades, schema changes, external API changes, rare failure modes in your application code, hardware failures.
It's also quite likely that different industries & different contexts value different kinds of boringness. E.g. large organisations running web services that need to be available (popular websites, ecommerce, banking) might value technologies that increase service availability, make it cheaper to hire and train engineers to maintain, and that can be deployed onto commodity hardware. Other organisations that ship software to embedded devices that are not connected to the internet and need to run in real time might value quite different dimensions of "boringness".