We have got the public comment

https://groups.oasis-open.org/communities/community-home/digestviewer/viewthread?GroupId=4861&MessageKey=28a65116-7c7d-4209-a406-f838996c9862&CommunityKey=96966655-9ba3-4069-82be-018f5aa7f7f2

The text is
Posted 09-13-2022 06:08
 
 
Hello,

in ODF 1.3 [1], the following definition is used for BIN2DEC (6.19.4):

> Syntax: BIN2DEC( TextOrNumber X )

The "TextOrNumber" is incorrect here: the X must be strictly "Text".
Rationale: the conversion is done from the textual representation, and
passing a number here would do a conceptually incorrect conversion
sequence (e.g., a number 10 (ten) would convert first to text "10"
representing the number in decimal, then treated as binary text, and
converted to number 2 (two)). This conversion sequence is definitely
not the intended use of the function (even though, indeed, possible),
and represents a user error. Thus, the function definition must not
"support" this misuse. The implicit conversion from numbers to text here
is orthogonal.

For DEC2BIN (6.19.7), the definition is this:

> Syntax: DEC2BIN( TextOrNumber X [ ; Number Digits ] )

Again, X is "TextOrNumber", but must be strictly "Number", allowing the
evaluator to do the implicit conversion. Even though here the "Text"
part is "harmless", it makes the DEC2BIN function "responsible" for the
conversion, while it's the evaluator that must do the conversion here,
according to the implicit conversion rules (6.3.5).

Indeed, the same considerations apply to other similar functions:
BIN2HEX, BIN2OCT, HEX2BIN, HEX2DEC, HEX2OCT, OCT2BIN, OCT2DEC, OCT2HEX
must take "Text"; while DEC2HEX, DEC2OCT must take "Number".

Interestingly, DECIMAL uses the correct "Text" type of its argument.

[1]
http://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part4-formula.html

–
Best regards,
Mike Kaganski