Conversions between any data type and the binary data types are not guaranteed to be the same between versions of SQL Server
Microsoft reserves the right to change the binary representation of the build-in data types like DATETIME. So if you do an

INSERT dbo.table(binaryColumn)VALUES(CAST(GETDATE() AS VARBINARY(8)));


and then you upgrade SQL Server or even do an SP apply

SELECT CAST(binaryColumn AS DATETIME) FROM dbo.table;


might get you a different date then the one originally stored.

However, if you store you own binary data that was generated outside of SQL Server (e.g. a pdf file), that data will not be affected by such a change. 

This by the way is not new. Microsoft always said that they might change the binary representation at any time. They might just have made it more obvious in the new BOL version.

That all being said, it is still very unlikely that Microsoft is going to change the binary representation of say an integer. However, something like a geospatial, which is implemented as a CLR type, is very likely to change between versions.



As per Paul's comment: SQL Server does indeed guarantee that you can convert a build-in data type to binary and back within the same statement. To extend that to the same session when storing the intermediate value in tempdb however I would already consider risky - a very small risk, but a risk. Storing the intermediate value in a real table to pick it back up at a later time is a definite no-no.