Because doing something like this is opinionated. The LaTeX developers try to do the opposite: they want to provide packages that cover as many usecases as possible.
And users of LaTeX are probably not knowledgeable enough or too busy to publish their opinionated subset of LaTeX as a class. I don't know for sure. There is no central body that has an interest in removing barriers, so you might as well ask me or yourself why I or you haven't published anything.
I developed something similar to this at my company, because we write lots of LaTeX documents and need shortcuts like this not only for brevity but also so that we achieve some consistency across the entire team. It's only for internal use though and thus not public.
As I said: Maybe you want to specify a different placement option like `b` instead of `t`. Maybe you don't want the label equal to the file path, in particular if you happen to include an image twice.
Or you don't want it centered. Or you want several images in one figure environment arranged in some way. Or you want to scale the included image to fit only 70% of the page width. Or maybe you want to rotate the included image by 90 degrees. Many more use cases are imaginable.
You could define the macro to cover all of this, but then you might as well just write the original code.
And as I replied: how does any of this *prevent* you from "cover[ing] as many usecases as possible" given that writing the original code is always an option?
The first (namespaces) contrast speed (brevity) and specificity (verbosity). Namespacing (long names) are great when you don't have a good idea the full scope - putting your library in namespace means you generally never have to be concerned that terms will overlap.
Macros tend to be the opposite - short, in global namespace, with little flexibility. They constrain the possible output by focusing on a certain goal - this is the point of the macro usually, to avoid some common pitfall without being overly verbose.
If you combine the two, you have a problem - either the macro dictates your preference, or many different macros must exist which, usually being brief or in pursuit of similar goals, will result in namespace collisions.
So of course you can define them, but generally this is better suited towards a specific use case or organization.
Or at least that's the idea. I'm not sure some standard approachable macros are a bad thing, as long as you can redefine them later or pick and choose, but I do get the point of "why not", because they don't want to constrain the language itself. The irony is other systems do this for them and tex becomes more an outsider thing and systems like markdown are far more constrained...
On the other hand there is no way to make everyone happy, and I respect the Tex author decision to opt for a less-is-more strategy wrt to offering building blocks only not templates.
You are of course free to build your template library, and make it popular, but be forewarned that likely whatever it is popular at doing (say, writing science articles), will affect what TeX is used primarily for. Which is the "why".
And users of LaTeX are probably not knowledgeable enough or too busy to publish their opinionated subset of LaTeX as a class. I don't know for sure. There is no central body that has an interest in removing barriers, so you might as well ask me or yourself why I or you haven't published anything.
I developed something similar to this at my company, because we write lots of LaTeX documents and need shortcuts like this not only for brevity but also so that we achieve some consistency across the entire team. It's only for internal use though and thus not public.