Use formal language when the audience demands it, and never otherwise. Why? Because your audience is human beings, not machines. Write for humans.
Even in reports and documentation, your audience will thank you if you sound like a human. Now, documentation has to be precise, and therefore has to define and use terms precisely. But documentation also contains description, and that description should be written informally when possible.
Basically IBM's rule seems to be: there's never a need to be _formal_, but you should be less conversational on specific tasks, and more conversational on high-level docs and marketing material.
I would say never use either. Strive to be plain. By plain, I mean both clear and unpretentious. This kind of writing doesn't have to sound informal.
This advice is not my own. It is ancient, and you could say it is the gist of books like The King's English by the brothers Fowler (1906), The Elements of Style by Strunk and White (1959), On Writing Well by William Zinsser (1976), and The Sense of Style by Steven Pinker (2014).
Bureaucratic language to me means wordiness, vagueness, and indirection. Conversational is often wordy too and likewise short on substance. But while bureaucratic sounds like it came from a robot, conversational puts the writer too much in the spotlight.
The reader comes to a piece of writing to learn something. The purpose of writing is to help the reader, as quickly and clearly as possible. The techniques in the books I mentioned, or on plainlanguage.gov, are meant to help you do just that.
This is generally good advice, but there are occasions in which the signalling value of jargon, formality, or complexity outweighs the value of clarity. If your primary goal is to appeal to an audience that values formality, it makes sense to be formal. Clarity is important, but it doesn’t override “write for your audience”.
In my experience writing reports on public health data, it depends on the audience and their intent. Lay people will skip (or worse, misinterpret) any paragraph containing "statistically significant." But the epidemiologists will want enough details to completely recreate my numbers.
I've settled on a mix: plain language that expresses intent and the key points (not just using a thesaurus to replace jargon). And at the end, a hyper-detailed technical notes, methodology, and references section. The goal is any expert who's read the tech notes can read the report and understand the assumptions and math behind each statement.
Personally, I like this kind of reporting. Read the tech notes to check that it's reliable, then read the report with peace of mind. I was going to "translate" the jargon into basic concepts anyway, so this saves a step.
Even in reports and documentation, your audience will thank you if you sound like a human. Now, documentation has to be precise, and therefore has to define and use terms precisely. But documentation also contains description, and that description should be written informally when possible.
Edit: Ignore this. ucarion said it better.