First check that the PA is actually enabled via the emberSetTxPowerMode() command or the MFG_PHY_CONFIG manufacturing token. More information about this can be found in the FAQs referenced at the bottom of this article.
Assuming that the PA is properly enabled, your range may still not be optimal, and here’s why:
While enabling a PA on one side may produce some marginally better performance, generally having PAs on both sides of the link is recommended, especially if the PA-equipped device does not also have an LNA (or something similar) to boost reception. The reason for this is that the PA only boosts TX power outbound from the device who has it; RX power is [all other things being equal] the same regardless of whether the PA is present. For example:
Suppose a node A has no amplification and generally can transmit well-heard signals at a range of X meters, and node B has a PA and can generally transmit well-heard packets out to a range of 4*X meters, and both have equal reception strength (no LNA).
Now if A and B are up to X meters apart, everything is fine (just as in the case where B has no PA); however, if A and B are, say, 2*X meters apart from each other, now B can send a packet (with its amplifier) that can easily reach A, but A is not capable of sending a packet strongly enough to reach B, so you have a grossly asymmetric link.
As a rule, the EmberZNet stack take measures to avoid these kinds of asymmetric links (because they are unreliable). However, if this is the only link that exists for A and B to communicate, the network will have a serious problem because B will send out messages to A that can be heard, but As return acknowledgments (MAC ACK and APS ACK) will not be heard (as they cannot go far enough), causing B to retry its delivery many, many times before finally having to give up.
Thus, either both sides need TX amplification, or the side without TX amplification needs substantial RX amplification (such as Boost Mode or an LNA).