I agree that hard forks are not strictly more severe (it depends on each case). But the distinction is meaningful and there are technical differences between them that one shouldn't ignore.
As I explain in the linked post, there is no technical difference. As the two events are usually defined, in both cases after the fork there are two versions of the rules, "permissive" and "restrictive"; and what happens next depends only on which version has the majority of the hashpower (which of course may change after the fork, and in principle could even go back and forth several times).
The system's evolution does not depend at all on which rules were in force before the fork (i.e. whether the fork was "hard"or "soft"). The only way to make the fork "safe" is for all miners to adopt the same version,
whatever that is, before the change is activated. If that is not possible, one must hope for a strong majority,
for either version, when the fork happens; so that the minority is motivated to switch too as quickly as possible.
Moreover, the soft/hard is an incomplete picture: there are changes that are neither restrictive nor permissive. In the extreme case, a "clean fork" is when the two rule-sets after the fork are totally incompatible -- no transaction or block is valid for both versions. IMHO, the safest forks would be such clean forks, at periodic pre-scheduled dates...