Well, there certainly are users which are not happy with just the full profiles and I am sure there are reasons. I do not say there is no need for more profiles, but until now I have not seen reasons for it, which justifies it.
For me, your arguments do not justify the complexity for users having to choose between profiles. If I start a project and having to make decisions on what profile to use, how would that be less expensive than running a cloud machine with 50MB more for years? Let’s take AWS for example, where a block storage costs about 0.1-0.2$ per GB per Month.
Regarding boot times, may you/one can specify what fast means? I have a wildfly app booting in < 10 seconds where a spring boot app I am currently working on (with almost just REST interfaces) needs > 15 seconds to boot.
If you think about the buzzword IoT, then clearly the full profile may not suit. But I am not sure if this has to be covered under Jakarta EE.
I am with you in terms of complexity and portability. For small applications, where mostly one war or app is deployed, it would be beneficial to be able to configure the Application Server (DB, JMS-Queues, …) with any mechanism from inside the war (let’s say a properties file or something). I would love to see such mechanisms in Jakarta EE, but this is not really related to profiles.
I also think it would be beneficial to have a legacy profile for the stuff that is not anymore ‘state ot the art’, so that the main profile could be more lean.
To be clear: I have no final opinion about this topic yet. I just like to see some valid arguments for having more profiles or for not have more profiles. What I also did not see in this discussion so far, are examples for profiles and how they fit together. This would help getting a clearer image of the needs from those who argue for having more profiles.
Dominik