They will need to keep the restriction on store apps (or at least mark store apps that do this with a big banner shouting "warning!" to users), because understanding how to secure these IPC channels is depressingly hard for ordinary developers (there were several hundred bugs filed by WinSec against this type of channel before Win8 shipped) - and that's even before you realize that a malicious app-store doing this gets medium integrity impersonation of the user on the desktop for free doing this.
Or in other words, this breaks the entire AppContainer security model by turning a download of one of these apps into effectively double-clicking an EXE you found on the Internet and hoping it doesn't pwn your system.
Generally, a better solution for store apps would be for Windows to be a bit more proactive at inventing and shipping new WinRTs.
For example, even on this forum some developers have asked for COM1 read/write from inside a Windows Store app. Now the correct approach to this is not for Microsoft to give developers medium integrity DLL execution. That's like your four year old daughter asking for a wendyhouse and you handing her a powerdrill and telling her she can build her own.
The correct response is to write a bespoke COM1-over-IPC channel - Microsoft is able to build and secure these because that's what WinRTs are. Microsoft should be proactively seeking out new ideas for WinRT that developers are really asking for, and implementing them and releasing them out-of-band with the rest of the release cycle of Windows.
Why should a developer have to wait until 2016 (or later, who knows?) before getting a feature that's make-or-break for their app? Like being able to 3D-print, or use a custom barcode scanner? Or maybe a banking app that interacts with a custom card reader or something?
It's nice that Microsoft is allowing developers to be flexible here - but developers need to be careful. That powertool is not only heavy and complicated; it's dangerous too.