This basically comes down to how Rust does type inference and type defaulting.
{integer} is how rustc prints out the placeholder type for an integer literal. It's not a real type; it needs to collapse to a real iN or uN type to be used.
And this is why trying to call .count_ones() doesn't work. In order to call a method with method call syntax, the type of the variable must be known at that point. In the example without the type annotation, the type isn't known when calling the method (it's still the placeholder type {integer}), so you can't call a method on it.
This error message could definitely be improved, or rustc could learn to deal with this, though it's more complicated than you might think.
Why it's complicated
Currently, it's a built-in limitation of type inference that "backwards propagation" of type information cannot flow over method invocations. Consider the following snippet:
let i = 42;
// i.count_ones();
takes_u32(i);
Here, i is inferred to have the type of u32 because it's given to a function that takes u32. If the method lookup for count_ones did the obvious thing and collapsed the type placeholder {integer} to the default i32, then you would have a type conflict, even though count_ones is defined for u32 as well.
Instead, we'd have to teach rustc what methods are available on all types {integer} can collapse to, so that the method call doesn't need to collapse the type. The current structure of type fallback (which only exists for {integer} IIUC) and the impls on primitives in the standard library do not allow for this in any way, and would have to be reworked to support it.