This is a good point and IMO "format code on save" should be the default in most IDEs and editors - that way if you need a specific set of formatting rules you can configure them, but you won't end up with no formatting (or different people having different ways of writing code) by default.
I think that Go in Visual Studio Code did something like that by default, where you saved your changes and it also formatted everything. Annoying at first, but I came to appreciate the idea.
You can technically achieve the same with something like Git hooks but setting those up is error prone and can be annoying once people get too trigger happy (e.g. someone eventually putting running tests in Docker containers in there before you can commit your changes).
To me code formatting feels about the same as the tabs vs spaces "debate": if you're having it in the first place, you're possibly doing something wrong. Use tab key for indentation, have the IDE insert whatever is configured for the project/org, be it tabs or spaces (e.g. smart tabs), automate it away.
Coming back to BlueJ: I appreciate that beginners have to be taught to format their code properly sometime along the way, but not at the very beginning. If you have errors, warnings, linter hints, typos etc. all being highlighted, I imagine that must be confusing as hell for beginners. Better focus on fixing the syntax errors first (or learning how not to produce any in the first place). Also, over-eager linters such as ESLint can really suck all motivation out of you when writing code. As for automatic formatting, that's fine with languages where it's near-universal like Go, but for Java you should probably refrain from adding it to a tool such as BlueJ, otherwise you will get the opposite of what you wanted (people get used to the IDE doing it for them and then neglect proper formatting when the IDE doesn't).
There is a world of difference between tools for learning how to code and tools for producing code.
Something students don't always realize is that their teacher doesn't need 30 copies of a program that prints "Hello, World". You are not "producing code", you are "demonstrating your understanding" of the content.
Autocomplete, autoformatting, auto-anything is harmful for the learning process. If the computer does it for you, then how do I know you know how to do it?
Once you can demonstrate that you know how to format your code properly, then those auto-tools can help you, rather than being a crutch.
Once you know "I can solve this problem by using a substring" you can use autocomplete to figure out the exact syntax for the substr() method. But if you're just looking through the auto-complete method list and clicking on things until one of them works... that's not "knowing how to program".
But it won't last forever, and what it does well - conveying often unintuitive OOP concepts - it does do well.
Your course conveners job its to teach the fundamentals, tooling is for you to shake out as you gain experience and scale up, and from their perspective - imagine trying to wrangle random IntelliJ/Eclipse issues with a cohort of 120+ students, for many whom this might be their first introduction to programming!
Scaling things back probably genuinely allows them to provide a better learning on ramp.
If you're learning to program for the first time, then i believe using a simpler tool is better, because there is less to learn all at once, and less that is hidden from you. I started programming in EditPad Lite, and that was absolutely what i needed until i started tackling larger projects, at which point it was worth spending the time to learn Eclipse.