OpenGL won't handle input or sound or physics for you, no. But there's no reason why you can't use other libraries to handle those specific sub-components and use OpenGL for the graphics.

Quote:
I just have trouble making 3D environment, handling the collision math, and making sure everything is efficient enough for something, say an FPS.

Then grab some libraries.
Use Bullet, Havok, PhysX for the collision and physics. (Bullet even comes stock with OpenGL based demos!)
Grab something like SDL to handle the input and sound for you.

Quote:
So I've heard (or should I say, I've seen all over the place) that OpenGL is the "industry standard". Now for those of whom, me too if I may add, who can't use DirectX and work in the industry do you only use OpenGL for graphics?

People who work on the XBox or PC have a tendency to work in DirectX. This is a huge market, and just as much "industry standard" as OpenGL. But you have to work within the limits of the hardware you are given. And, like you said, not everything supports DirectX.

Anyone working on cross platform stuff (like how Valve's Steam Engine is now on Mac) use OpenGL.
Anyone working on the iPhone, Android, etc. is going to be using OpenGL:ES.
Anything that runs linux and has graphics capability will be running OpenGL or OpenGL:ES. (though DirectX works in Wine).

There are lots of platforms that are CLOSE to OpenGL, like the PS3, Wii, PSP, DS, etc. And tonnes of platforms that require, or allow, direct assembly programing of the graphics chip (like PS2, N64, DOS, etc.).

Alternatively, you could take a look at a more out-of-the-box solution, such as Unity. It gives you a development environment for 3D games, with things like collision and input available to you via C# scripts.