Is it just me, or does this paper lack any real "meat"?!
I'm not familiar with what that really means, just jumping to an assumption about the intent of the paper that I think was not made clear in the title as is.
It comes down to making a good choice in each of the following areas. (My choice is in parens, along with my comments.)
Cloud Platform (For historical reasons I am on Azure. I have some experience with Google. It does not hurt of course to work in several, but the cognitive overhead of gaining a real in depth devops knowledge on very many platforms will be overwhelming for many people, especially as the vendors invent stuff on the fly.)
Relational Database Management System (Strive to learn SQL and 1 or 2 platforms, mine is SQL Server, as best as possible. There is only one useful data model, and it is the relational model. You will store data with other means over your career, but learning them is mostly trivial, and if your are intentionally using a different data model than relational, you should have a good reason. Also learn to data model using natural keys. This is a huge topic unto itself. The main justification is it will simplify the queries you end up using. A friend of mine is working on a book on nat keys. There is a real shortage of good literature on this topic.)
An application programming language (Mine is F#. Learn one or 2 languages well, chosen because the compiler and canonical workflows do so much to keep you out of trouble. You will have to know 1 or 2 scripting languages our of necessity. Given the other areas you need real expertise in, I am not a fan of spending a lot of time with the language of the month club. Become an expert in the language(s) you use. It's a career-long pursuit.)
Project Management (Recently saw a good overview video of the "no estimates" approach. I was sceptical before I saw it. Not really impressed by Agile, but I don't want to wade into that swamp.)
Specification Language (A new area for me. I am interested in TLA+, but I'm still learning it. The idea of a specification language that delivers an unambiguous spec at an arbitrary level of granularity that you can manipulate and refactor is very appealing to my sense of propriety. We spend too much time going straight to prototype in our favorite language, refactoring it, etc. TLA+ forces you to focus on actual spec and not implementation details. The prototype approach leads us all to confuse implementation and spec.)
1) There is no substitute for the relational model. Clearly it is a paradigm for building mathematical objects.
2) I didn't strongly advocate my choice of F#. Strongly-typed, functional first, ML syntax language is the sweet spot today. In theory this predicts faster development and fewer bugs. All software assemblies are mathematical objects, those built with strongly-typed, functional languages tend to be more humanly comprehendible.
3) No estimates allows practitioners to make useful projections of the course of a project. (Of the 4, this one has the weakest claim to belong to theory, yet I will argue useful projections are a kind of prediction.)
4) TLA+, or something like it, separates spec from implementation detail and makes "predictions" (at arbitrary level of granularity) of what a completed software component will do.
But I don't disagree with you. It's important to learn those things.
And, to be perfectly honest, the technological stack is maybe the minor part of engineering a software system, both because compositions at different scales are already well defined and because the actual complexities are outside software selection and well into the user-software-developer interactions and specifically in non functional requirementd.