Nice clear and unambiguous question. Back to basics, really. Possibly difficult for people who are used to working with ANSI WARNINGS ON, but pretty basic for the rest of the world.
The explanation is a bit incomplete though. The reference is to the right BOL page, but the text quoted from that page is actually irrelevant because it's saying that even when ANSI_WARNINGS is set to ON some statements (parameter passing to SP or to UDF, assignment to variables) don't follow the ansi standard for treating overflow and zero divide errors that occur in INSERT or UPDATE statements - actually I can't understand why anyone would think it might or should, but there's no harm in making it clear. It says nothing at all about what happens when ANSI_WARNINGS is set to OFF and that's what the question is about. There's no text at all in the explanation that describes what happens when ANSI_WARNINGS is OFF.
In fact some of the other text on the BOL page is a bit of a mess:
Bol
When set to ON, the divide-by-zero and arithmetic overflow errors cause the statement to be rolled back and an error message is generated. When set to OFF, the divide-by-zero and arithmetic overflow errors cause null values to be returned. The behavior in which a divide-by-zero or arithmetic overflow error causes null values to be returned occurs if an INSERT or UPDATE is tried on a character, Unicode, or binary column in which the length of a new value exceeds the maximum size of the column. If ANSI_WARNINGS is ON, the INSERT or UPDATE is canceled as specified by the ISO standard. Trailing blanks are ignored for character columns and trailing nulls are ignored for binary columns. When OFF, data is truncated to the size of the column and the statement succeeds.
The third sentence appears to say that NULL values occur when zero divide or aithmetic overflow errors occur and ANSI_WARNINGS is OFF, and that this includes the case when INSERT or UPDATE tries to stuff more into a character or unicode column than will fit. However, this is contradicted by the sixth sentence, so perhaps the third sentence applies when ANSI_WARNINGS is ON? But that would contradict the first sentence! The obvious correction is to get rids of the third sentence and make teh fourth sentence say that it applies to putting overlength data into character, unicode, or binary string columns (ie grab the last bit of the third sentenbce and put it into the fourth sentence).
It isn't all that unusual for a BOL page to be a bit of a mess, but it usually gets fixed when it's pointed out. This time MS has left it a mess for a decade or more after it was pointed out to them (the offending text dates from BOL for SQL 2000, or perhaps even earlier).
edit: spelling
Tom