I think it's universally accepted that #include <bits/stdc++.h> is bad practice, in part because it parses and includes every standard header, which is almost always unnecessary (it's also nonportable, but that's beyond my point). It's even worse when combined with using namespace std; because now you have a ton of common names in your namespace, like next.
Yet, it seems that #include <Windows.h> is mostly deemed to be OK (it's used by most Win32 programs I've seen), even though it conceptually does the same thing as a combination of #include <bits/stdc++.h> + using namespace std;.
According to Wikipedia:
windows.h is a Windows-specific header file for the C and C++ programming languages which contains declarations for all of the functions in the Windows API, all the common macros used by Windows programmers, and all the data types used by the various functions and subsystems. It defines a very large number of Windows specific functions that can be used in C.
Why is this the case? Is it not possible to include specific headers we use and not include <Windows.h>?
Msdn documentation explicitly tells you (a) in which header file a function is declared and (b) which header file you are supposed to include.
Most functions tell you to include windows.h, for example SendMessage
Some function, that were added later or have very specific use cases, are only available through other header files, for example SetupDiEnumDeviceInfo.
So no, it is not bad practice to follow their advice. However, I strongly recommend disabling some parts of it before including via macro, e.g.
#define NOMINMAX
#include <Windows.h>
because otherwise you will get a min and a max macro that will interfere with std::min and std::max.