I really like this, but I also like strong typing, and somehow it feels I cannot have both. Smalltalk, Ruby, LISPs (Clojure) in one corner A, and Rust, Haskell, OCaml/ReasonML/Rescript, Elm, PureScript in the other corner B.
A: quick to "compile", so fast write-run-try loops, very runtime inspectable/updatable, less noisy syntax; but also easier to make runtime errors, larger test suites, less easy to refactor.
B: refactorability (especially with good IDE support), strong runtime correctness guarantees; but also long compile times, and no cool runtime inspection/update wizzardry.
It is not statically typed, so given a variable you can not know from the variable which type it currently holds. But in Ruby you can always know from the object itself which type it is.
That said there's a lot of work going on in Ruby to allow you to get more certainty statically about types. See e.g. Sorbet
What is strong typed is not well defined. But mostly people use it for langs that use the typesystem to prevent as many runtime errors as possible. Features like sum-types, and explicit nullability are often mentioned in that regard.
Ruby and Smalltalk have neither and do not so much try to avoid runtime errors. They tray to allow runtime inspection, and runtime fixing.
I strongly disagree that this is how it normally used.
Both Ruby, Smalltalk and e. g. Python are generally regarded a strongly typed on the basis that no conflicts can occur to trigger undefined behaviour or runtime errors that are unrecoverable due to lack of type safety causing the runtime environment to be corrupted, coupled with the explicit typing of all data and limited implicit conversions.
In fact, a someone who has worked on a Ruby compiler, merely defining what meaningfully constitutes an error in Ruby is one of the big challenges with compiling it, because a program is free to define how to respond to any kind of type error in whichever way which makes most sense. Or to check and assert types however strictly you want.
While you can throw an exception you might call a runtime error, that does not imply a failed or crashed program unless you want it to, because the runtime environment does not get corrupted by it. A runtime error in Ruby can be part of the normal life cycle of an application that includes recovery.
My editor for example will not crash in the face of a "runtime error". A bug may trigger errors, sure, but they are all trapped and correctable from within the running editor itself. It's not unusual for me to keep my editor running for months at a time.
At the same time, nothing stops you from doing sum-types or explicit nullability in Ruby if you want to with some creative meta programming. People have built stricter type checks for Ruby as long as it has been around. It was almost a rite of passage for some time, but people tend to stop when they learn to use Ruby properly. A key aspect of learning Ruby properly is to learn to not fight the type system and only check the things that actually matters. When you do, you find a lot of type checks quickly becomes a smell.
But by your own criteria, the ability to completely trap and recover and prevent all runtime errors and the ability to define arbitrarily powerful typing systems, Ruby is strongly typed.
Just not statically typed.
Of course with 3.1 you can increasingly do static type checking too, though that will take time to mature and is not a replacement for strong typing at runtime.
And this one contradicts both cies and me, but it's in no way authoritative of anything.
Here are a few alternatives (equally unauthoritative, but demonstrating my use of the term):
"Strongly typed is a concept used to refer to a programming language that enforces strict restrictions on intermixing of values with differing data types. When such restrictions are violated and error (exception) occurs." ... "Examples of strongly typed languages in existence include Java, Ruby, Smalltalk and Python. In the case of Java, typing errors are detected during compilation Other programming languages, like Ruby, detect typing errors during the runtime." [1]
...
"Dynamically typed languages (where type checking happens at run time) can also be strongly typed. Note that in dynamically typed languages, values have types, not variables.
A weakly typed language has looser typing rules and may produce unpredictable or even erroneous results or may perform implicit type conversion at runtime." [2]
...
"A strongly-typed language is one in which variables are bound to specific data types, and will result in type errors if types do not match up as expected in the expression — regardless of when type checking occurs." [3]
This last one gives a clear delineation which mostly matches how I use it (e.g. C and PHP described as weakly typed - C allows you to override types and PHP does all kinds of nasty implicit conversions; conversely while specific Ruby API's may do conversions, the type system does not and do not allow implicit conversions, and do not allow you to coerce your way past the type system)
You can find all kinds of other variants, so sure, it's not a term that has a definition that everyone agrees about. Your linked article has a point that it's a term one need to define.
I however stand by my assessment that the definitions in most common use fits Ruby.
A: quick to "compile", so fast write-run-try loops, very runtime inspectable/updatable, less noisy syntax; but also easier to make runtime errors, larger test suites, less easy to refactor.
B: refactorability (especially with good IDE support), strong runtime correctness guarantees; but also long compile times, and no cool runtime inspection/update wizzardry.