As said above the Effects framework is an additional layer on top which gives you some higher level of abstraction.
It's not deprecated in any way, it's only provided outside the DirectX core, and also in source code form (which means you can see what it does under the hood and tune it to fit your needs).
The biggest disadvantage of it, as mentioned above, is that it's really easy not to use declarative buffers at all and create unoptimized code if you're not careful (you can use separate buffers using effects framework and it's pretty recommended to do so).
This is perfectly valid using effects framework:
cbuffer cbPerScene : register( b1 )
cbuffer cbPerObject : register( b0 )
When you modify a variable it will mark it's parent buffer as "dirty" , and update accordingly (please note it only updates resource when you Apply Pass, not when you set a variable).
Now some advantages of it.
- Layout validation : It will verify that data you pass between shader stages are compatible (data passed from vertex shader to pixel shader for example). In a production environment it's not too useful, but a design stage it's quite handy.
Reflection/Semantics : Having the ability to enumerate individual variables and attach semantics to them allows to have some dynamic pipeline, which can be really useful for prototyping (as soon as you recompile your shader you can automatically create gui elements for variables to test it, semantics are commonly used for global settings, for example:
float4x4 tViewProjection : VIEWPROJECTION;
you can detect the semantic and automatically send your camera transform.
So now when you do a lot of draw calls with plenty of different material shaders, it's true that it can introduce some performance hit (even tho in modern dx11 programming Instancing and using Buffers/StructuredBuffers is pretty much the way to go), for other parts like post processing the hit is generally very minimal.