Yes, this is dangerous (and, frankly, stupid).
Obviously, this is catastrophically unsafe if the app contains a CA certificate with the private key. That would give the attacker complete TLS spoofing capability on any client which trust the CA cert.
If the cert is only for a specific domain, that's less disastrous but still dangerous. At attacker can only hit that specific domain - probably just one app that uses it - but this could potentially be very bad anyhow. Depending on what permissions the app has, and how the domain is used, the attacker might be able to gain control of the app and execute arbitrary code as the user.
Even for an app that is intended to only connect over loopback, there's two threats.
- Over the network: If the app doesn't modify the HOSTS file (no, telling the user to do it for you doesn't count; software shouldn't introduce a massive security hole and then tell you to go edit a weird file to fix it), then the name lookup will fall back to DNS, which is (usually) trivial to spoof.
- Local attacker: Even if the app successfully ensures that only loopback addresses will be used, using a publicly-known private key means an unprivileged attacker on the same machine could potentially spoof the server (or client, for that matter) to attack a different user (potentially with greater privileges, certainly with different ones). There are ways that the app might detect such tampering (for example, trying to start the server first, and not continuing if it can't bind the port) but there are ways that an attacker might bypass that (for example, finding a message that crashes the server, and sending it as soon as the server starts, then starting their own in its place). People tend to forget about local EoP attacks, but they shouldn't; even if you're the only human user of your machine, local EoP can be used to break out of sandboxes for untrustworthy or high-risk apps (browsers, store apps, etc.).
The thing is, there's just never any good reason to do this. For most inter-process communication, you should use almost anything except network sockets, TLS-protected or not. Named pipes, mapped memory, local (Unix domain) sockets, any of the many platform-specific options... there's no lack of choices that are faster, more reliable, more capable, AND more secure.
The only exception is if you're using a webview in a local app for some reason, and need to point it at an HTTPS server specifically. In that case, you should do the same thing that you should do any time you need to trust a local TLS server: generate a CA cert + private key locally, install the CA cert locally (typically only for the current user!), and then generate a private key + certificate signed by your locally-generated CA's private key. This doesn't even require elevated privileges (unlike modifying the HOSTS file), no two installs will use the same private key, no other users on the machine have access to either private key (indeed, once the CA key is used to sign the domain-specific cert, it can be deleted entirely), and you aren't at any risk of your CA revoking your certificate for flagrant misuse of its private key!