How would you design it? Accept messages of any length, reject messages over maximum length?
If you did that, and no error handling was implemented in the IoT device, it would merely result in a non-event that no one knows about.
In this specific instance, the author is doing the right thing. The developer will see truncated messages running through.
In the end it is a question on desired semantics. The semantics of the operation in question is obviously to truncate and process rather than fail.
What makes you think that the API described in this post would be subject to those kinds of legal and/or regulatory requirements?
Could it be the case that the author knows prima facie that no such requirements exist for their service?
If I target use cases that prefer truncation of messages to errors, then surely it's acceptable for me to build it that way, right? I'm not saying it's a good idea in general. I'm saying it can be acceptable in the appropriate context.
(I actually agree with you, I think it's a bad rule of thumb. I prefer Fail Fast (and loudly)).