And we know that knowing of $Q$ and $P$ is sufficient to be able to compute $d$ efficiently.
I think you meant "knowing $P$ and $d$ we can compute $Q$ efficiently. That's the DLP as stated in your previous answer.
I think it's more intuitive to work in $\mathbb{Z}_p^*$ and in this group you might reframe the DLP question as this: "given some generator $g$ for the group $\mathbb{Z}_p^*$, what's the difference between computing $g^d$ for some known $d$ as opposed to just computing $g^k$ for each $k \in \{1, \ldots, p-1\}$?"
In terms of complexity we measure operations in terms of bits of input required. It turns out we have a good algorithm for exponentiation called exponentiation by squaring. The cost of calculating the exponent is explained on that page - in essence, to compute $x^n$ we need $\log_2 n$ square operations and $O(\log_2 n)$ multiplications - that is, at most $\log_2 n$ operations on bits. Considering that squaring approximately doubles digits and considering multiplication to cost $O(d^k)$ operations for some constant $k$ the page comes up with a bound. The complexity they give is:
$$O((n\log_2(x))^{k})$$
i.e. polynomial in terms of bits.
A naive way to solve the DLP is to compute $g^k$ for each $k \in \{2, \ldots, p-1\}$. For this we simply need repeated multiplications modulo $p$ as we can hold the last value. As before, the cost is $O(d^k)$ for two $d$-digit numbers. In terms of bits, the order of the group is $b=\log_2(p)$. Then we need $O(2^b b^k)$ multiplications, in terms of bits, assuming all integers take $b$ bits and are prefixed with zero.
Another way to think of this is that the maximum space required to represent a prime $p$ is $b$ bits and our algorithm must touch each element in this space - $2^b$ elements.
There are of course some important caveats to this - there are better algorithms than trial multiplication and depending on the group they might be fatal for crypto purposes. But essentially that's it.
This is expanded upon in the answers to "Why is the discrete logarithm problem assumed to be hard?" (not by me).
The double and add method follows the same principle - the cost in bits of an operation for a known coefficient $d$ can be expressed in some polynomial form, while evaluating every possible multiple of the generator (and thus the entire group) is significantly more costly as the size of the group increases such that no polynomial time algorithm is known. In EC, we tend to operate over a cyclic subgroup of the group of points under point addition such that every point is a generator.
Additional extras you didn't ask for but since your previous answer mentioned it :) Let's go back to the $\mathbb{Z}_*^p$ group for this. A number is $B$-smooth if it can be completely factored into primes less than a given $B$. For example the order of $\mathbb{Z}_{181}^*$ is $180 = 2^2 \cdot 3^2 \cdot 5$ and this is say 7-Smooth. We can use this property to use the index calculus algorithm to (more) efficiently (than brute force) compute the DLP. Or as your first answer mentions, any other algorithm relying on this property.
We defend against this by choosing a "safe prime" or a strong prime i.e. one such that $2p+1$ where $p$ is prime. This means the order of such a group is $2p$ and as such there is a large prime order subgroup order $p$ (group contains subgroups of order factors of the order of the group by lagrange).
There is a very important difference between the group of points on an elliptic curve and the multiplicative group of integers modulo $p$ - there is a corresponding integer ring in which unique factorisation into primes holds. We have no such equivalent in elliptic curve group. See this question: Trying to better understand the failure of the Index Calculus for ECDLP Consequently our groups need not be as large (we no longer need a large prime order subgroup).
As a further aside, an excellent article on Dual_EC_DRBG is this proof of concept which works with C/OpenSSL. Maths included.
