1. Do employers care about Microsoft or Cisco certificates?
No, they care about you being able to do your job and unfortunately in programming there's no qualification that really proves that. Have a portfolio. Also a lot of places will expect you to take a short practical test before they hire you. That's not to say that the certs won't improve your chances of getting your foot in the door and having the interviewer actually spend the time looking at your portfolio or whatever, but they're no substitute for real proof of ability.
2. What is the most lazy laid back programming field that makes a living wage? How does one get into it?
I'd say there isn't really a specific field that's good for laid back. It's much more a question of where you work than what the company does. Maybe PHP/javascript/webshit? Just because it tends to attract the worst programmers, so if you're good you'll look like a superstar even if you laze around for 6 hours a day.
If you're more interested in computer work in general than specifically programming, system administration and security mean a lot less in the way of deadlines though you will have to deal with the occasional massive emergency.
Avoid COBOL. It's what I'd answer if someone asked "I don't care how shit the job is, I just want to make the most cash" COBOL was long out of date in the 90's and it was a flaming pile of shit when it was first released. There are only a few domains (e.g. banking) that still use it because the managers have an "if it ain't broke" attitude and now that all the old COBOL programmers are retiring they're doing the only thing they know how to do and throwing more money at it. You can get entry level 6 figure positions.
Ah, gotcha. Is there any particular language you'd recommend as being a good example of "the functional side" to start with?
I'd say common lisp and haskell. There are two big sides to the functional side and they're the poster child for each one. Lisp is more about homoiconicity, where all data including the program code itself is represented in the same basic manner. Haskell is the group theory side, where it's all about types and the translations between them.
The big thing to understand about programming and paradigms is anything can solve your problem and the measure of what the "best" is what's the easiest to use and understand. This leads to a feedback loop. If you've spent your whole life doing C then it's the best for everything because it's really easy to understand and all the other languages are hard to understand because they're not C. That one time you tried to see what all the fuss was about and use lisp it was nowhere near as good at being C as C was.
This is exacerbated by the fact that more than just being able to solve your problem, most languages can ape the features of other languages. C++ has lambdas, they just kinda suck. So if you go into C++ as someone who uses lambdas all the time it'll work but you'll wonder why you aren't just using a language with good lambdas. A decent way to check if someone is blinded by bias towards their way of doing things is to ask them for domains in which other paradigms do better, if they can't give you some real examples...
In reality all methods have their ups and downs and what's "objectively" the best is heavily dependent upon the domain and, if you're trying to do practical real world stuff, is often outweighed by stuff that has nothing to do with the code at all. If you want to start a business that produces some desktop gui program, C# might be your best choice not because it's the best language but because it's easy to hire C# devs who're good at making desktop guis.
So yeah, if you're new and you don't care about jobs then shop around and see what works for you. If you do care about finding a job, especially if you want to work in some specific domain, then look up which languages are actually used in those domains. Some languages are much easier to find work with than others.