Well, it is true that you can write PowerShell with Notepad and debug in the command line shell. It is a question of what works best for you.
As for packaging code as an executable being a bad idea, I don't know, that is of course defined by your internal policies. I humbly submit that because a variety of these tools exist, there obviously is a need for them.
As for PS2EXE-GUI, I had a quick peek: "Unfortunately Ingo seems to have stopped working on his script so I overworked his script with some error fixes, improvements and output support for non-console WinForms scripts (parameter -noConsole to ps2exe.ps1)." So you have to ask yourself, do you trust your business needs to 'a guy' (PS2EXE was not created by Microsoft) who simply may stop being interested in the tool that you use or a company that has been in this business for over twenty years. That is your decision of course.
I am also not sure how packaging PowerShell code with our packager would 'marry' your code to our tool? We charge no runtime fees and it is a means of publishing the product, not a means of storing your code. Of course we strongly encourage you to store your code safely, preferably in a version control system, so that you do *not* create any dependency. That is just standard procedure, one would assume.
Different entities have different reasons for packaging code, you must decide which one applies to you. I am not sure how packaging defeats any of PowerShell strengths, you are still in possession of the code, so the clarity and maintainability remains. That would mean any compiler, .NET or otherwise would do that too, which simply is not true. Some of our customers chose to package PowerShell code to keep unskilled users from attempting to fix things they should not touch. Having a signed and sealed exe erects an additional hurdle to end-users modifying code and possibly causing damage. That is just one reason though and brings us to the security question....
Of course packaging code into an executable does not mean you are now free to put sensitive information in your code. You should never do that. Nor does it provide absolute security against anyone reading your code.There is no such thing as absolute security. "Security through obscurity is not security at all…" That is a rehash of one of the Microsoft PowerShell Team members speaking at a conference.
What it should say is "Security through obscurity alone is insufficient security." Security is always like an onion. More than one layer is required and you decide how many you and your organization needs.
If security is your concern, you should probably hire a dedicated IT security expert or consult with one and not only listen to presentations at a conference. I hope you already do that. It is a complicated and multi-layered subject (pun intended) and having a professional assist in this matter would sure help.
My favorite analogy on this subject is as follows: Not leaving your valuable visible inside your car and locking your car doors is no measurable defense against a professional car thief and a tow truck.
Common sense though and all professional advice dictates it is a good idea though and everyone does it (mostly). Ask your "no security through obscurity" folks if they then leave their cars unlocked and their laptops in the passenger seat at Walmart, since it doesn't matter anyway.
It appears to me that your Dev team simply wants to use these tools as they are from Microsoft and it is what they already use. I would like to point out that there is absolutely no reason for this type of exclusivity seemingly portrayed by your team. Any developer, PowerShell or otherwise, should always be versed in multiple tools and languages and any attempt to create a 'pure', singular provider environment creates the dependency your dev team seems to advise against.
Sometimes Microsoft tools have a tendency of disappearing into the fog of time as the teams move on to newer and greener pastures.
I recall having this very same conversation a few years ago about the ISE, since "that is all what one needs and it is free". It is now no longer developed or maintained by Microsoft as far as I know.
Ultimately, not knowing your position and who decides what in your company, I would advise all of you to sit together and discuss what is best for your company now and in the future, rather than arguing about solid and absolute positions. Things move and develop and having multiple tools and skills with the inherent flexibility it provides, seems to deliver a better outlook on adapting to future business needs.
As always, happy to help and I hope this provides you with some talking points.