Thanks for your feedback. It's much appreciated. While I understand your perspective I maintain a difference of opinion. For example:

"it is possible to implement "everything is an object" in Perl ... which isn't bad, but no particular benefit either"

You're right to call out that this is a move towards "everything is an object" in Perl. As mentioned in another comment/reply, "the lack of a native type system means that your classes and methods can’t be certain of the type of data they’re being passed, which forces you into a position of defensive programming".

"Venus::Number objects can, thanks to overload, be manipulated with the usual arithmetic operators. However, as soon as I apply an arithmetic operator on a Venus number, the result loses its object properties and is just a plain number."

You're correct and this is intentional. All value class methods, intentionally, return native data types. I refer to this in the article under "guiding principles" where I state that "the library should ease the multi-paradigm identity crisis" and "be a compliment, not a cudgel", i.e. if I'm using Venus and (in a particular context) I only want to leverage the Venus::Array#any algorithm (e.g. Venus::Array->new([1..8])->any(sub{$_ > 5})) I can use that and have the result be a basic arrayref, OR, if I want to opt-into "everything is an object" and chaining method calls via autoboxing I can do that easily too (e.g. Venus::Array->new([1..8])->box->any(sub{$_ > 5})->count->unbox).

P.s. Thanks again for the great feedback. Based on it I'll be adding the simple math routines to the Number class in an upcoming release, as well as fixing the string interpolation bug.