Let's be honest here: how many actually distinct paradigms are we really talking about here? I challenge you to name more than 5 which are not just flavors of the same core approach. Bonus if they are actually all relevant for production software.
For declarative, where you describe what you want, not how to get it, you have Prolog, Make and SQL (maybe others but I haven't heard of them). Yes, they technically aren't purely declarative as they usually have an escape hatch to imperative for performance reasons, but you can get quite far with them just in a declarative style.
The imperative, where you tell the computer how to do something, you have procedural (Pascal, Ada, C, BASIC, Cobol, Fortran) that's your classical programming style of actions working on data. There's object oriented (Smalltalk, Java, Erlang) which structures things a bit differently than procedural, where data is told what to do (via methods or message passing). Functional languages are more about avoiding globals and controlling side effects (and typically are lazily evaluated, but I don't think that's foundational to functional). You have concatenative (Forth, Postscript, Joy) which centers around a point-free style of programming (implicit data on the stack instead of explicit in variables) and data-flow (or array-centric) languages (APL, J, K) which work natively on array data.
Each of these paradigms have their pros and cons. Procedural if you have a lot of actions on a small set of types. Object oriented if you have a lot of types and a small set of actions. Functional if you want easy-to-reason about code. Data-flow to help with parallelism. Concatenative if you don't want to name piece of data. Declarative to have the computer figure things out for you. All of these I can see a reason to use in production.
Python and Lua being probably the most similar of the bunch. The point is not that you would use any of these production (although you could), the point is to get your feet wet in a new setting. You see what's different and what's the same. I think it's a very important part of maturing as a programmer.
I was asking about paradigms. These are 6 languages and the distinct paradigms they cover are hardly 6. Unless we have different notions of what a paradigm is.
I see imperative and functional paradigms covered in your list. Am I missing anything else? Object orientation could be counted as a separate paradigm but how much different that is from basic imperative programming is already somewhat debatable.
There’s OOP with message passing (Smalltalk, Objective C) and there’s OOP with functional flavor (CLOS in Common Lisp).
I do agree that collecting paradigms is more interesting than collecting languages. Like logic programming (prolog), array and stack programming (uuia).
All of those languages are very different in how they handle concurrency, safety, objects, meta programming, etc, in ways that force you to adapt how you approach and deconstruct problems. Certainly not as much as a whole different paradigm would, but still in ways that are valuable to explore.
Why it should be relevant for production software?
That's not true at all. In first place, what you can think is good for production, i can think otherwise.. Beside it there is a lot of things/paradigms/languages that we learn, to help us to either understand better the basics or because it is easier for beginners. There are a lot of Science and Research that you can just throw away, but that was super important for further development. Pascal, Smalltalk, Minix are example of technologies, that we learn(ed) and not necessary are widely used in production. Haskell helped me to understand is pure immutability is actually practical or not, and so on..