This is apparently a really common question. As far as I can tell, yours is the first one on Stack Exchange to ask about the benefits and/or history, rather than just asking what it means, so I'll answer it here directly.
.d just means "directory". As far as I can tell, this became a thing with sysvinit, with the
/etc/rc.d folders. These, always contain separated configuration files that are parsed or invoked by some other process.
As to why this is done, a few reasons:
Imagine if your init process was controlled by a single configuration file. That file would become large and unwieldy. Web services like
nginx use this paradigm to encourage separation of individual websites or vhosts into their own configuration files. (This folder is called
sites-available in most distros Nginx packages, but it also has a
conf.d folder that generally applies to settings that apply everywhere)
Security separation (somewhat). Separate config files allow different permissions on each file. If one user were trusted to modify a service or setting relevant to them, they could modify only the files they have rights to, rather than giving them the rights to the "one file to rule them all"
Ease of troubleshooting/reconfiguring. Going back to nginx, say you needed to disable a specific subdomain. With each site broken out into its own configuration file, you can just rename or remove that one file rather than going into a single large file and commenting things out. The same applies to init - usually on sysv systems, init scripts are taken into and out of service by adding or removing symbolic links. This handles runlevels and so forth. No need to invoke a text editor.
All of these benefits are gained for a very minute increase in complexity.
Terminology? I don't think there is anything official for this design, everyone just calls them "dot d folders".
Some further reading: