I find it easier to keep things modular as the routing model, services, templates and ORM allow you to put code where it belongs. I never quite manage the single responsibility ideal, but I find Laravel helps.

This really depends on the scale of your micro service and the requirements. Go is great at handling async/concurrency based work and scaling well. Node is probably more suitable if you're just writing a small API to support internal work. I imagine more people can develop for Node than Go so that's something to think about in terms of ongoing development and support.

Out of interest, was the question really regarding JavaScript or Node? Node implies server side development, JavaScript could be either; JavaScript is the only way to really develop client-side browser code and is therefore already enterprise by lack of choice.

Charge them for what they want, then you'll always make money. Explain that supporting legacy browsers incurs time and therefore cost to them. Unless it's only legacy features you're going to use, in the case of some government or intranet based scenarios, in which case it's probably not a problem.