To me, a blockchain is a way of solving double-spend problems in a Merkle tree maintained by open distributed consensus, by using some scheme to resist Sybil attacks. The scheme is not necessarily proof-of-work, but the fact that there's a double-spend problem and you're solving it is key to the idea.
If you don't have a double-spend problem because all your transactions commute (e.g., Certificate Transparency), you don't have a blockchain, just a Merkle tree. Which is great, you don't have to incur the costs of mining at all, nor do you need to think about mining incentives and structures.
If you're not using distributed consensus because you have a central coordinator, you don't have a blockchain either, and again, you get to not think about mining. Whichever transaction reaches the coordinator first wins, so double-apend becomes irrelevant.
If the Fed wants to build FedCoin, I don't see any reason why they should refuse to be the central coordinaor and instead outsource consensus to the internet. I don't see any reason why they would, if they want to influence monetary policy at all—70% of Bitcoin mining last year was in China, which meant that it would have been straightforward for China to (globally!) freeze a Bitcoin address, and a little more complicated but still possible to prioritize or throttle certain transactions.
Maybe being protocol-compatible with Bitcoin or ERC20 or something would help, but fundamentally this would be an API to transfer USD, not a decentralized system.
See also patio11's Tweet https://twitter.com/patio11/status/583698553614143488 "Most advantages of Bitcoin which matter are captured by, and improved upon by, a LAMP app which simply holds account balances." If the Fed wants to build that app, great!