Well it's quite simple. Imagine you have a function f() which takes an
integer parameter named x, and somewhere applies bin() to this parameters.

Right now, if you call f(1.0) instead of f(1), you will get a TypeError,
which is easy to detect: you then fix the call to f(1), and bin()
produces the expected result ('0b1').

With Raymond's suggestion, if you call f(1.0) instead of f(1), no
exception will tell you your mistake, and bin() will produce a
completely bogus result compared to the expected one. If you notice the
bogus function output and find out that it contains a strange-looking
string (something like
'0b11.001001000011111101101010100010001000010110100011'), it is still
not obvious from it that the problem stems from passing a float instead
of an int. Especially if f() is a library function which you didn't
write yourself.

There is a reason Python recently introduced a stronger distinction
between ints and floats (for instance the __index__ method, which bin()
seems to use currently), I don't see the logic behind trying to undo it.

And it's not like printing the bin() representation of a float has any
actually use (besides education, but education can use its own tools
rather than builtin functions).