When you're starting out - worry a LOT less about such things. Simple-to-understand, working code should always win over complex designs. Architectures are opinionated, have inherent pros/cons/trade-offs and you can really paint yourself into a corner.
That out of the way - here's why they are useful/important:
They have pros (and cons). This needs to be said up-front. There can be unfounded/unfair hate for some patterns. Classic is the monolith. Each pattern has pros/cons and they should be evaluated. Example: Monoliths are great for a single engineer hacking like crazy on fast-moving project. Don't be a hater - be an engineer and pick what's appropriate for the task 😉
They give the team a common language. If I say "MVC" to an engineer - they already have a visualisation forming in their mind about what-goes-where. The same with software [design] patterns.
They define what-goes-where in both code and hardware. This can make it a lot easier to organise the source code, but also the team, responsibilities, cost allocation etc.
They help with convention over configuration. Configuration is bad (generally) it means someone needs to do something. Conventions (that are well-understood - like those in patterns) are good. People expectX and it just happens. Magic! ✨ Examples are auto-routing and resolution of views in MVC. Gone are the days of mapping - most frameworks do it all automagically.
They're tried-and-tested. They work! People have refined them over time, improved them, optimised infrastructure set-ups for them - this means you can have a bit of trust in them - without the foundation/backing knowledge.
There's a few things - but first I'd say this:
That out of the way - here's why they are useful/important:
Xand it just happens. Magic! ✨ Examples are auto-routing and resolution of views in MVC. Gone are the days of mapping - most frameworks do it all automagically.You are actually quite clear. Thank you.