When initiating new projects and sharing it with third parties, many developers prefer licensing under the "short and simple" permissive MIT, Apache or BSD licenses, which are indeed providing short term advantages.

• Less red tape and complex legal statements;
• The provided source code could be faster accepted and reused in other projects, increasing chances to become "a reference" or "a standard";
• Permissive licenses implement no restriction for reusing the software in other projects, even "proprietary": there is no obligation to publish the source code in the case of re-distribution;
• Copyleft licenses like the GPL or the AGPL stating that in case of distribution, software "using" any part of the covered source code must be covered by the same license appear as toxic for most business environments, fearing the obligation to share their own proprietary code due to some "viral" effect.
• At the contrary, permissive licenses boost informal sharing and reuse. Even for public sector administrations like in France, this is a good reason to recommend it  as a preferred option.  

However, when an open source project becomes successful and is gaining economic value, copyright owners becomes reluctant to see vendors copying their code, making no, few (or unknown/hidden) modifications and selling the software as their own property. This was the case of the WLED software, now used by a community of 30.000 members and projects making it the most used Led management software that is now present everywhere: from basic Christmas lights to the most sophisticated and coloured light shows. The project recently released its new version under the EUPL instead of the MIT (see REDDIT discussion here).  The main change is that economic stakeholders will not be able to fork WLED into their closed source software. They'll have to keep it open source. The choice of the EUPL, which is much more moderately "share-alike" (compatible with similar licences) and "weak" rather than "strong copyleft" and which, governed by European law, is never "viral" looked a reasonable compromise given the number of vendors now selling products based on the software.

For the public sector stakeholders, the alternatives are similar: is it better to give away public code without any obligation to maintain it open or to respect the principle that "public money should produce public code"?
There is no general rule or imposed choice: common sense must guide the best path.