The inclination towards exposing BOLT12 invoices stems from considerations of code simplicity and reduced specification work. It presents an easier path than integrating blinded paths into the existing BOLT11 framework. The error handling benefits of using BOLT12 invoices are acknowledged; however, there is skepticism about its effectiveness in encouraging user-driven demand for wallet updates. This skepticism is rooted in concerns over user experience, particularly the scenario where users are confronted with error messages upon scanning incompatible QR codes, which might not sufficiently motivate them to seek enhancements from wallet developers.

On the other hand, the potential of blinded paths, especially in the context of sub-swap services like the L402 protocol or similar offerings, is highlighted. Blinded paths offer significant advantages for these services, such as enabling the receiver to influence the routing of transactions to optimize for lower fees or reliability. Despite these benefits, there's an underlying belief that retrofitting blinded paths onto BOLT11 invoices would ultimately be counterproductive. The argument posits that such short-term fixes lead to higher long-term maintenance costs and complexity, suggesting a more holistic adoption of offers (as facilitated by BOLT12) could provide a cleaner solution. This perspective underscores a broader preference for forward-looking solutions that address underlying structural needs rather than temporary workarounds.

For further details, the discussion can be found in the GitHub pull request comments here, which provide insights into the evolving viewpoints on this technical matter.