You seem to misunderstand the consequences of this POSIX requirement.
Something that does not end in a newline just is no line.
This results e.g. in wc reporting 0 lines if a file contains no newline at all, which is true even on Linux.
Your added new question looks a bit different from the first question, as it asks for specific use cases and resulting problems.
First, a longer file that does end in a newline causes other problems that are not related to Linux. If a C include-file does not end in a newline, this may cause a C-source that #includes this file to fail if the text on next line in the C-source only works as expected in case that it is on the beginning of a line.
Furthermore, there are some programs that ignore the last line in a file if it is not terminated by a newline.
Software like SCCSv4 and SCCSv5 classifies a file to be "binary" if it contains a nul byte or does not end in a newline. This results in sub-optimal handling of deltas.
Finally, LSB is a binary standard internally to Linux, but files are copied between different platforms and even if LSB would differ from POSIX in this area, this did not change the relevance of the rules from POSIX.
Maybe it helps to know that in former times, there was no editor on UNIX that could create a file that does not end in a newline. The first editor that could create such files was the Gosling EMACS from 1979 followed by VED from UNOS (the first UNIX clone) in 1980.
So it seems to be good practice to tell your users to avoid such files...