There are different answers here depending on which REDIST packages we are actually talking about.
In most cases, the reason that REDIST packages are used is because the components involved require administrator rights to install because they install drivers, update system components, install files into
%WINDIR%\System32, and/or install Windows Services. For User Account Control support, you can really only require administrator rights at install time, not every time the application is run.
Visual C++ REDIST packages
The rules here have changed over the various releases of Visual C++, so some of the usage here is based on simply looking for the easiest and quickest solution. In most cases, games already have an installer that requires administrator rights so it's just easiest to launch the VC REDIST EXE (either x86 or x64 depending on their game EXEs) to deploy the CRT DLLs system-wide.
Application local deployment (i.e. just copying the DLLs with your game EXEs) is an option, but for security servicing it's actually nicer to have a system-wide version that gets patched automatically as needed. For VS 2005 / 2008 the Fusion Side-by-side manifests tried to make it possible to service even local deployment, but it was a bit flakey. As of VS 2010, the use of these old manifests were removed so if you use local deployment you have to update your application to apply any CRT security fixes.
The only really good reason to do application local deployment for the Visual C++ CRT is if you are trying to avoid the need for admin rights for deployment, but you have to take responsibility for security updates and don't get anything 'for free' in this regard.
Windows Store apps do not deploy the CRT. It's taken care of by the system.
DirectX REDIST (aka DirectSetup)
The answer here is that most developers are using the REDIST because they don't understand what it actually does. Or more importantly, what it doesn't do. Ideally, most games would never use the legacy DirectX SDK anymore (see Living Without D3DX), but there are still a few specific scenarios where you need to rely on it. And the main reason they use the REDIST is that the License Agreement doesn't allow you to do application local deployment of any of those DLLs.
Back in the day, DXSETUP installed DirectX components like DirectDraw, Direct3D, DirectSound, etc. The modern REDIST, however, never installs DirectX components. As of Windows XP Service Pack 2, these are all part of the OS and are only updated through Service Packs, Windows Updates, or new versions of the OS.
The legacy DirectX SDK REDIST is still required to deploy D3DX9, D3DX10, D3DX11, XAudio 2.7, XInput 1.3, XACT, or D3DCompile #43.
XAudio 2.8, XAudio 2.9, and XInput 1.4 are part of the Windows 8.x and Windows 10 operating systems, and again are never deployed by the legacy DirectX SDK REDIST.
D3DCompile #46 and #47 are available to be deployed application local in the Windows 8.x SDKs and Windows 10 SDKs. D3DCompile #47 is part of the Windows 8.1 and Windows 10 OS, so you don't have to deploy it application local for these platforms. Ideally you'd never do any HLSL compilation at runtime and ship all your shaders prebuilt, but you need the D3DCompile DLL to use any shader metadata reflection APIs. D3DCompile #46 and #47 are never deployed by the legacy DirectX REDIST.
Windows Store apps can't use the legacy DirectX SDK REDIST at all. They use the built-in OS components, and all DLLs that they ship in their AppX package must meet the API restrictions of the WACK validation tool.
Note that if your game is actually using something that the legacy DirectX REDIST installs, you should take a look at using the April 2011 update of those files--the
.CAB files were not changed, just the DXSETUP files.
See Not So Direct Setup,
XAudio2 and Windows 8,
XINPUT and Windows 8,
HLSL, FXC, and D3DCompile