What do the scripts in /etc/profile.d do?

Why are these files not a part of /etc/profile if they are also critical to Bash startup ?

If you mean, "Why are they not just combined into one giant script?", the answer is:

1. Because that would be a maintenance nightmare for the people who are responsible for the scripts.
2. Because having the scripts loaded as independent modules makes the whole system more dynamically adjustable -- individual scripts can be added and removed without affecting the others. Etc.
3. Because they are loaded via /etc/profile which makes them a part of the bash "profile" in the same way anyway.

If these files are application-specific startup files not critical to Bash startup, then why are they part of the startup process ? Why are they not run only when the specific applications, for which they contain settings, are executed ?

That seems to me like a broader design philosophy question that I'll split into two. The first question is about the value and appropriateness of using the shell environment. Does it have positive value? Yes, it is useful. Is it the best solution to all configuration issues? No, but it is very efficient for managing simple parameters, and also widely recognized and understood. Contrast that to say, deciding to configure such things heterogeneously, perhaps $PATH could be managed by a separate independent tool, preferred tools such as $EDITOR could be in an sqlite file somewhere, $LC lang stuff could be in a text file with a custom format somewhere else, etc -- doesn't just using env variables and /etc/profile.d suddenly seem simpler? You probably already know what an env variable is, how they work and how to use them, vs. learning 5 completely different mechanisms for 5 different ubiquitous aspects of what is appropriately named "the environment".

The second question is, "Is startup the appropriate time for this?", which begs the objection that it is not very efficient (all that data which may or may not get used, etc). But:

• Realistically, it is not all that much data, partially because no one in their right mind would use it for more than a few simple parameters (since there are other means of configuring an application).
• If it is used wisely, with regard to things that are commonly invoked, then setting, eg, default $CFLAGS from a file somewhere every time you invoke gcc would be less efficient. Keep in mind that the amount of memory involved is, again, infinitesimal.
• It can involve systemic things which more than one application may be involved with, and the shell is a common ground.

More could be added to that list, but hopefully this gives you some idea about the pros and cons of the issue -- the major 'pro' and the major 'con' being that it is a global namespace.

Those files are specific to an application, but are sourced at shell startup, not when the application starts. A configuration directory is used here for the same reason that it is found in many other places. This allows an application or software package to modify configurations. This wouldn't be possible without a split configuration, as multiple packages trying to manage/update a single configuration file that can also be modified by the user would be buggy and messy.

Also a side note, /etc/profile is sourced by all shells, not just bash. The bash specific configuration file is bashrc and only sourced for interactive shells.