By design, EdDSA requires a $b$-bit string as the secret key $k$, and when signing, it is expanded to a $2b$-bit string $H(k)$, some bit-twiddling is done, and the first half is used as the private key in the signature. [1]
The curve will have a $b$-bit security level, and solving discrete log can be done in $b \over 2$.
Why is it that EdDSA requires a $b$-bit secret key instead of only $b \over 2$-bit which seems like it would provide the same level of security as the curve itself?
One possible reason (and probably the one that was behind that design choice) is to avoid multi-target attacks.
Consider a setup where there are $k$ public/private key pairs, and the attacker's goal is to find one of these private keys. The attacker does not care which private key is obtained; getting any of them is a "win". For instance, the attacker wants to make a fake X.509 certificate by recovering the private key of a certificate authority: any private key in a chain to any root CA in the set of trusted root CA will do. A brute force attack on the $b$-bit seed will succeed with average cost $2^b/k$ (the attacker computes the public key for each potential $b$-bit seed, then looks up the public key in the set of targets; the looking-up does not involve complicated maths and can be done in "negligible" time, compared to the computation of the public key). If $b = 128$ and $k$ is large, then this can be substantially less than $2^{128}$.
From an "academic" point of view, this means that 128-bit seeds only provide "64-bit security": if there is a set of $2^{64}$ targets, then the attack succeeds in cost $2^{64}$, while the defenders collectively spent an effort of only $2^{64}$. Bumping seed size up to 256 bits is an easy and inexpensive way to prevent that kind of academic break.
The reason the private key is approximately the same order as the curve is due to the number of possible public keys being equal to the order of the cyclic subgroup generated by G.
This varies from curve to curve, but ultimately a shorter private key would end up excluding some possible elements of the subgroup, weakening the crypto.
The fact than the DLP can be solved in 2^n/2 is irrelevant here, as that attack doesn’t brute force the keyspace. It uses Pollard Rho.
Whilst it’s true some curves generate a relatively smaller keyspace than 2^n such as curve25519, whose co-factor effectively results in a keyspace of (2^n)/8 we still use 32-byte keys for simplicity and cross compatibility. Libraries will clamp keys as necessary.
