At least in the case of Python, "batteries included" decidedly works badly when it comes to graphics. The really usable and used GUI and graphics libraries for Python are all third-party.
You're making the situation far simpler than it is.
Extra batteries imply a greater codebase that has to be maintained, must support all modern architectures and compilers, and must evolve in a graceful way while maintaining backwards compatibility.
In general, backwards compatibility is a pain in the neck and results in libraries not evolving once they reach the standard library.
Python has tons of examples: urllib, urllib2 (both of them superceded by Requests, an external library that manages to incorporate a sane API), multiple subprocessing libraries, several refactorings of the OS exception hierarchy, etc.
Oh, and nobody actually uses the included GUI library for anything except the smallest of trivial examples.
This is something that can be tolerable in some high-level languages where performance is not a concern, but systems programming languages should tend to more conservative defaults and things that can be used in production to a certain degree of satisfaction.
Nobody is going to be happy with the default GUI lib in at least one of the many platforms; the existence of dozens of UI toolkits with different idioms, different looks, and different levels of integration are proof of that. And contrary to some more basic use cases, UI libraries tend to be, by necessity, absolutely enormous.
If the end result is going to be another poorly-designed library like many of the STLs modules, I'd much rather developers use the proper UI toolkit for the situation.
The goal is to have something that any programmer can use regardless of the the operating system.
Libraries in C and C++ are a pain to use, because they are only available for specific operating systems, specific compiler versions and tend to lack compatibility among themselves.
This pain also tends to be part of C culture, as other system programming languages already had the tradition to provide a proper set of libraries on their runtimes.
I think the main cause is that UNIX is actually C's set of libraries, but those libraries do not exist in all operating systems.
However having a set of libraries as default, is great for the guarantee to be able to write OS agnostic code.
No one is forced to use them, if they required more advanced use cases.
Like I said before, nobody is going to use an OS-agnostic UI library because UIs imply necessary integration and a level of specificity that can't be generalized.
There's half a dozen blitting models with difference performance optimizations. You have at least 4 or 5 popular widget toolkits. Do you support 2D drawing? 3D?
There are some things that just can't be abstracted away without massive engineering costs. No portable standard UI toolkit would be complete and compatible enough to be used for serious applications unless they're willing to stoop to levels as low as Java's so-called "multiplatform" UIs, which honestly look like crap.
A UI toolkit that's low-level enough is useless in desktop and modern mobile platforms. At higher levels they're too OS and device-specific. If they're too device-specific they have no place in a standard library. Thus, no UI toolkit is apt for this space unless you're willing to settle for mediocre, second-class toolkits.
> Like I said before, nobody is going to use an OS-agnostic UI library because UIs imply necessary integration and a level of specificity that can't be generalized.
Begineers and people that care about presenting simple stuff will do surely use it.
The idea is to have good enough libraries to write portable code for simple stuff.
Should anyone have to go though the pain of creating a OpenGL context, matrixes and shaders to put some text on the screen?
You are always free to go write Win32, Xlib, Qt, GTKmm, MFC, Motif, wxWidgets, WPF, embedded Chrome or whatever UI flavor of the months is for REAL applications.
"Batteries included" works very well in many cases. Having a single de-facto dominant implementation helps.