Just some thoughts... these are my opinions as someone who's been doing web dev since before CSS and JS were invented. They're just opinions, feel free to disagree :)
1) Where to learn... LinkedIn Learning (Lynda) was super helpful to me in my career. Affordable and excellent lessons + projects and well worth the money, no matter what you want to learn. MDN and Stack are great for questions once you start coding sample projects.
2) I think you're really asking more about "lower vs higher" (levels of abstraction), rather than simple/complex. There is nothing inherently "simple" about managing your own cron jobs, DBs, load balancers, VMs, etc. Each of those, at the right scale, can be a full-time career unto itself if you choose to specialize in it.
On the other hand, a "full stack" web dev can do a little bit of everything juuuuuuust enough to get by, which is often enough for simpler teams & projects, but can sometimes make it harder for others to maintain/scale up. A lot of basic web technologies were invented in the 90s and 2000s under the constraints of those days and it takes a lot of patience and know-how to get them running at scale and still provide a good developer/devops/orchestration experience.
Every project and org is different and there's not necessarily a "correct" level of abstraction, just different business needs and personal preferences. Each stack is a set of tradeoffs between user experience, developer experience, familiarity, cost, openness, maintainability, stability, etc.
At the end of the day they all compile down to the basics: HTML + HTTP. The user doesn't know what your stack is and the browser doesn't care.
3) IMO, the stack you choose shouldn't be based on some rigid ideology that you brought with you, but on finding (and, rarely, inventing) the most appropriate set of tools for the project and the people working on it. To that end, "production ready (yet simple!)" can mean something entirely different from one team/project to the next.
For example, an ecommerce site with 10,000 flat handwritten HTML pages is dead simple... no database, no proxy, no load balancer, no CDN, no HTTPs for most of it. And it's also a pain to maintain or upgrade. On the other hand, a Next.js hybrid app might have fewer lines of code, but if your devs are all used to Shopify templates or WooCommerce or some homebrewed Rails app, having to retrain everyone in a new stack may not be worth it. All of those are going to create a somewhat usable website for your end-users, but they each entail a very different set of developer skills & preferences.
4) If you don't know what level of abstraction you would prefer to work on (i.e. bare metal vs Vercel), start from the middle, which is where they all meet anyway: HTML + CSS. There is no reason to learn the old HTML syntaxes or older versions of CSS. Get really comfortable writing plain HTML in a single file or two, using modern CSS (grid and flexbox, etc.). Try to make a simple blog page using just those two tools, with no backend and no templating and no frameworks. Once you thoroughly understand how that one single page is structured, parsed, and presented by the browser, you can better understand the tradeoffs various levels of abstraction give you.
Let's say you want to hook that simple blog page up to a backend now. You can roll your own DB, spinning up your own Maria/MySQL/Postgres/SQlite DB. How will you do that? How will you make it reproducible on the server that you eventually host it on? How will you sync up DBs between your dev machine and the server? How will you scale this up to 10,000 or 10,000,000 viewers/mo? Can multiple editors work on it at the same time? Will there be multiple geographical regions you would want to replicate across? (Not trying to answer for you, just pointing out some of the interesting questions to solve).
You can do all of that on bare metal. Or a local WAMPServer setup. You can put it in a Docker container, or maybe orchestrate it with a tool like Lando. Or put it inside Kubernetes. Or outsource some of it, either to a cloud VM like EC2 or a managed DB like DigitalOcean's or ElephantSQL, or all the way to an abstracted headless CMS in the cloud like DatoCMS or GraphCMS. Each level of abstraction trades off some level of control/maintenance/cost/transparency/lock-in/etc. Again there is no right answer, just what is right for your project and/or personal preferences.
Back to your blog post, but focusing on the frontend now: You've outgrown that simple blog post and need to add more frontend look & feel kinda stuff. Do you stick with vanilla HTML + CSS? You certainly can. Do you need to make it work with phones? You can write a bunch of media queries, combined with grid and flex. It's plenty powerful, just a bit of work. Are you sick of having to do all that yourself? UI frameworks like Bootstrap exist specifically to make that easier. Or is that still too basic? There are more opinionated/higher-level design frameworks like MUI (derived from Material UI) that provides not only basic primitives but higher-level components (like Autocomplete, or a date picker, or a card with avatars and such).
That's just the styling.
What about the interactivity? What happens when you want to add commenting, categories, search, filtering, user logins, roles, etc.? That's where the really fun/tricky stuff comes in. You can 100% roll your own for all of that (somebody did, obviously, or the web wouldn't have that stuff) or you can use someone else's drop-in solution (like Discourse for comments) that's basically just copy/pasting a single script injection. Or take something like filtering... you can write that as backend (sanitized) queries that the frontend sends back, the BE parses and queries for, and then returns the result set. What does that look like? Does the backend prerender the entire HTML page and send that back? Does it cache any of that? If so, how does it invalidate? Or does it only send back the result set as raw data (JSON/XML/Msgpack/etc.)? Or would you rather handle some/all of the filtering on the frontend, hiding/showing HTML elements with some light Javascript? Do you write that JS yourself and handle state changes, or do you use jQuery/React/Vue/Svelte/Angular?
Then, when you combine ALL of these concerns, you can start to fully evaluate more complete frameworks like Next/Nuxt and understand their pros and cons better.
Some devs prefer to maintain control of everything. Some hate the backend and want to outsource as much of that as possible. Some hate the frontend and want to outsource as much of that as possible. Some want a little bit of everything, but less day-to-day tedium & instability. There's a hundred frameworks out there, probably enough to meet any desired level of abstraction/modularization.
TLDR: There isn't a single right answer to the question of "bare-metal v. vps v. vm [vs managed host vs serverless vs edge KV vs Jamstack vs App Engine/Amplify vs serverless]. Each type of abstraction evolved organically to meet some perceived need that the ecosystem wasn't previously meeting. Most often, a solution gains popularity when it can meet 80% of common needs with much less work -- but it would be the wrong choice for the other 20% of needs, and so another abstraction appears later. Some choose to forego that game and completely maintain their own stack, but you usually see that either for super small projects (a lone dev or two) or giant multinationals who can own their own silicon designs all the way up to global data centers. In the middle, where most projects and businesses sit, everyone chooses SOME particular abstractions to hand-wave away the parts that aren't mission-critical that they don't want to spend time maintaining/configuring. That's the hard part to figure out, and it takes a while to get a feel for it. So don't go in assuming that you either need bare metal or the highest levels of abstraction; you can't know that beforehand. Learn the middle and go up or down as your evolving needs dictate, but be open to different solutions... at the end of the day, web is a common problem and there are a lot of good (but different) solutions out there, each existing for a reason.