The OP's description of the situation is likely one-sided. That's ok.

I am an aging developer (~54 yo) brought into a company to not rule, but to provide some experience. (The IT boss actually said "gray hair", lol.) The dev staff was far more adept, on the balance, than any team I had worked with previously. They taught me a lot, especially about humility! But we found places where their technological wizardry didn't solve the problems and in some cases hid those problems, ultimately making them worse. This is where I was able to really contribute.

Your lead sounds severely autocratic. It sounds like he's been given a mandate by the owner. The owner is unhappy with the dev staff and has brought in this "hard-nosed no-nonsense go-getter" guy to improve delivery speed.

First, look at your staff. Do you have weaklings - developers who do not "see the Matrix"? If so, find them new positions within the company or give them a good reference for an employer who needs their unique skills.

He hates IDEs

I know a few that do. It makes me roll my eyes, but ultimately I do not care. If people produce using vi , then ok. I love my IDEs.

He doesn't refactor the code, and doesn't care about style (which is inconsistent across his own code)

Red flag on the first part. Is he a copy-paster? I am also guilty about not caring about style, but that's because I use my IDE to instantly make my Python code PEP8 compliant. But he does not use an IDE...

As a side note, style was previously checked by a nightly build, which started to fail since the arrival of the new lead. He rejects the idea of a nightly build, as well as automated tests. According to him, “any professional developer tests his code anyway by hand, so there is no reason to waste time writing automated tests”. The nightly build is also a waste of time, according to him.

This also sets off a red flag, but for different reasons than you might expect. Before this guy was hired, how many times was the owner told that he could not do X (give a demo, use the system, etc) because the nightly build failed? What if the owner perceives that the nightly build is the problem? What do you think he'd tell the Lead to do?

But I have concerns about the Lead's attitude; automated tests are amazing. As before, the boss might not understand the value of the tests, but he surely knows that Y% of the dev staff's paychecks are paying for them. When I arrived at my present company, the "100% test coverage mafia" had taken over the dev staff and ran costs waaaay up. One bad apple later and the dev staff was purring again.

He thinks that version control is mostly useless...

This is a red flag of the highest order. He is as wrong as possible. He is being irresponsible with the owner's money.

He overstates the importance of code optimization.

Back in the day, code optimization could make a difference. Now machines are so fast it is less important. Instead, we now need to worry about database performance and network throughput. But his "code optimization" habit is a hard one to break, trust me. I have to make myself not pre-optimize. At least his behavior in this case is not destructive, except for the time taken. (Do you have numbers for his "half his time" or is this hyperbole? If you are critiquing your supervisor, no hyperbole can be allowed. You must be pathologically objective.)

He writes all SQL by hand, and rejects the idea of an ORM.

Guilty as charged! I do not understand peoples' fear of SQL. I do not understand burying SQL, which is drop-dead simple, under layers of ORM that obfuscates. Can't help you here :-D But please, dump all your SQL into one place - don't distribute all throughout your code.

and two of the five developers never used SQL before.

That's unacceptable. This is 2016. They need to skill-up.

He rejects frameworks and third-party libraries, considering that it's much easier to write stuff from scratch.

He could not be more wrong. I doubt your company is so special that your utilities need to be written in-house. We had a few developers that would embrace 3rd party tools - until they did something in a way the dev didn't like. It was an excuse to throw the tool out and write their own. This just adds to the load on the dev staff, slowing them down further. This unhelpful code is expensive to write, test, debug, and maintain. We spent so much money for -zero- benefit. These developers are gone now.

He decided to abandon all JavaScript libraries and frameworks except jQuery, claiming that when he started programming in JavaScript fifteen years ago, there were no frameworks, and the life was much easier.

This one is not so clear cut. The reason is that life was much easier 15 years ago is that the business ask was much much simpler. That's where the problem has come from. The web was invented as a batch system (fill out a form, submit it, get a response, repeat) and now we're trying to write web apps that behave like desktop apps. His observation is right, things are hard now. But he does not realize why. Tool complexity is in response to a more complicated business ask. Thus he makes poor choices.

We're using AngularJS and it seems to be decent. Like all powerful tools, it can be used for good or evil.

He thinks that mobile devices (including tablets) are just a hype, so there is no reason to waste precious time to ensure the compatibility of the site with those devices and to make responsive design. The product is a public web application which is not expected to be used a lot from mobile devices.

He's wrong again. They are not hype. They are here to stay because they are useful. BUT the business does not need it. Don't develop things you don't need. It's expensive.

Responsive design, however, could be very interesting to have for this app,...

Is it so interesting you'd pay for the development personally? If this is a good idea, you ought to be able to sell the idea to the owner. Otherwise, don't spend a dime on it.

He asks the team to stop using internet (especially StackOverflow) and rely on their brains, the offline documentation (I didn't even know Microsoft still sells MSDN CDs!) and the books.

He's wrong. The internet is great for this. If the dev staff is copy-pasting from Stackoverflow without understanding how the code works then they are wrong too. Is there time for training and personal improvement in the development schedule? It's hard to not robotically copy-paste when you're always under the gun.

While I have limited information, there are lots of issues here. It sounds like the owner hasn't gotten the code he is paying for as quickly as he expects. It sounds like he's heard a lot of excuses about things he cares nothing about; he's focused on the result. If I am correct, you have a self-inflicted wound, and you have re-opened it more than once. This Lead is the owner's solution to the problem the dev staff has posed, and given his limited information, it is understandable.

I will also bet you're running a non-agile shop and have poor requirements definition which changes as the wind blows. There isn't a layer of insulation between the dev staff and the owner. Except for this Lead.

Now, what can you do?

1) Train the lead that the use of automated testing and code management is the way to go. It may take time to gain credibility with him - the owner has probably told him the staff is defective. See if you can prevent him from making sweeping mandates such as "delete all that useless testing crap and repurpose the SVN server". This will give you time to show value.

2) Continue using code management at a personal level. At least then you can recover from your own mistakes. Don't tell him you're doing this, though don't lie to him either.

3) Continue automated testing (unit tests, if nothing else) at a personal level. As before, don't mention it though don't hide it.

4) Work with the Lead to determine what the actual perceived problems are. Be open minded; I bet there are real issues with the staff. Work with the lead to address the problems, not the symptoms.

5) Discuss with the Lead various development topics, such as the benefits of waterfall and agile. Neither is perfect. Ask him questions such as, "Under what circumstance would automated testing be worthwhile"? If he gives a dubious answer, ask him how successful companies like Google have managed to thrive in spite of it.

So you can see I'm all about engaging the Lead and seeing where his head is at. Build trust. Agree on issues versus symptoms. This is not always easy, especially when you feel he's like Godzilla and is tearing your work apart.

There is a chance he cannot compromise. He will crush automated testing. Code management is for careless people. My Way or the Highway.

If it has gotten to this point, however, it will be time for you to leave. Working in a tool-less shop, and I mean software and software engineering tools - does not build your resume. You will begin to rot the same way the Lead has rotted. In that case, move on.