Let me try to make it clear...
1. Not anyone, but only hardware vendors can make extensions. It is logical since extensions are part of the drivers, and only driver writers know what their hardware supports.
2. If only one vendor supports some functionality, then appropriate prefix/suffix is used (NV, AMD,...) Sorry, Brother Bob, for repeating this.
3. If at least two vendors support some functionality, then EXT prefix/suffix is used (prefix for constants, suffix for functions).
4. If at least two vendors support some functionality, and the committee (ARB) decides it is something that should be a part of the core, the prefix/suffix changes to ARB.
5. Almost all ARB extensions become core functionality in the next revision of OpenGL. In the recent years, ARB extensions are published at the same time with the new release of the specification of the core, so ARB overnight becomes core. Core names lose ARB prefix/suffix.
6. If the driver supports particular ARB extension it also supports core equivalent (please correct me if I'm wrong; maybe there were some functions differ from the core version in the list of parameters), and vice versa. I saw a lot of advices on the forums claiming that ARB version of the function should not be used if the core version exists. Well, if the core version exists, both ARB and core functions point to the same entry. The function pointers are identical. Do you think driver writers would implement several version of the same function? Be aware, OpenGL is a mammoth with decades of adding new functions. Also, it doesn't matter how the function is named. You can use whatever name you want as long as you are accessing the right pointer. void glVertexAttrib1f (GLuint index, GLfloat x) has the same functionality as void Marry (GLuint index, GLfloat x) if they point to the same entry, have the same return-value and use the same parameters.
7. The extensions names returned by glGetStringi(GL_EXTENSIONS, i) should report the functionality. If there is no adequate ARB string, the functionality is probably not supported even if should be included into the core of the version the driver supports. You can be a 100% sure only after retrieving the function pointer and try to execute it properly. Considering OPs question, I can bet that mentioned functionality (part of GL_ARB_robustness and WGL_ARB_create_context_robustness) is not supported in any form.
8. Claiming that appropriate version of OpenGL is supported is not a guarantee that it is true. I won't start a debate about it, but there is a plenty of examples.
9. Starting from OpenGL 4.0, the addition of new functionality does not follow new hardware capabilities. For example, 82% of OpenGL 4.3 functionality is supported by the old hardware (SM4). The same is true for OpenGL 4.1 and 4.2 (70+%). So, even if a driver claims it supports OpenGL 3.3, it actually could support more than 70% of all versions above (up to 4.3). The exception is only OpenGL 4.0, because it requires SM5 hardware exclusively.
Sorry for repeating your words, Brother Bob and Mhagain, but I tried to summarize all you sad. I hope it is clearer now.
Everything said by Brother Bob and Mhagain is correst, but maybe it sounds a little bit complicated (although it is not).