Having a single DC makes disaster recovery more complicated. It's always more convenient to have a second DC, and a cheap insurance policy in the event of failure of the heretofore singleton DC.
Being a DC is going to cause additional resource utilization on the member server (overhead in hosting AD, clients performing authentication against AD). It will also change the resultant set of group policy applied to the machine, so be wary if you've done anything with group policy to get the application the member server is hosting to function properly (assigning user rights in GPOs, etc).
On a modern server computer with a small number of clients the resource utiliation will be negligible. Any group policy-releated settings you've already applied to this server can still be applied after it's promoted to being a DC, if necessary.
If the manufacturer of the semi-mission-critical application is alright with running the application on a domain controller then I see no reason not to promote the member server hosting the application to being a domain controller. While you're at it, I'd install the DNS Server role and make it a Global Catalog Server as well.
Whether or not this will disrupt access will depend on whether the application needs any other resources hosted by the existing DC. Assuming that the member server is configured to act as its own DNS server, it will be capable of fulfilling any of its needs associated with authentication itself. If it needs shared files or other resources from the existing DC, though, just making the member server a DC / DNS server won't be enough to prevent disruption.
(A very small terminology nit to pick: There are no "primary" or "secondary" domain controllers in Active Directory. They're just domain controllers.)