I found that there was a slight degradation for each thread up to three or four, then it went downhill quite fast -- while I was working out an optimum for one of my systems, I found 2 three-thread tasks worked the CPUs harder than 1 six-thread task did

First question to ask is did you preserve the file type as an .xml file? Make sure you didn't create it as app_config.xml.txt.
BOINC will ignore the file if not named correctly.

Second question is do you see the app_config being read for Einstein in the Event Log at startup?
If you don't see the file being recognized by BOINC it isn't being acted on and is being ignored.

Both cases would explain why your tasks are still being sent as 16c tasks. Also, any old tasks in your cache before you made the change will still show as 16c. All new tasks will have the correct intended parameters.

<app_version>
    <app_name>milkyway_nbody</app_name>
    <version_num>182</version_num>
    <platform>x86_64-pc-linux-gnu</platform>
    <avg_ncpus>16.000000</avg_ncpus>
    <flops>89728291437.088242</flops>
    <plan_class>mt</plan_class>
    <api_version>7.6.33</api_version>
    <file_ref>
        <file_name>milkyway_nbody_1.82_x86_64-pc-linux-gnu__mt</file_name>
        <main_program/>
    </file_ref>
</app_version>

<avg_ncpus>1.000000</avg_ncpus>

<app_config>
<app>
    <name>milkyway</name>
    <gpu_versions>
        <cpu_usage>1.0</cpu_usage>
        <gpu_usage>1.0</gpu_usage>
    </gpu_versions>
    <max_concurrent>4</max_concurrent>
</app>
<app>
    <name>milkyway_nbody</name>
    <plan_class>mt</plan_class>
    <avg_ncpus>1</avg_ncpus>
    <cmdline>--nthreads 1</cmdline>
    <max_concurrent>1</max_concurrent>
</app>
</app_config>

I have dozens of tasks for MilkyWay@home, almost 200. Is this normal? Seems it would be an inefficient way of doing things.

It's their project and they like multicore tasks as opposed to running one task per cpu core, you can always limit it with an app_config file

<app_config>
<app>
    <name>milkyway</name>
    <gpu_versions>
        <cpu_usage>1.0</cpu_usage>
        <gpu_usage>0.5</gpu_usage>
    </gpu_versions>
    <max_concurrent>4</max_concurrent>
</app>
<app_version>
    <app_name>milkyway_nbody</app_name>
    <plan_class>mt</plan_class>
    <avg_ncpus>1</avg_ncpus>
    <cmdline>--nthreads 1</cmdline>
    <max_concurrent>4</max_concurrent>
</app_version>
</app_config>

Ok, time to turn in my "guy card" and give y'all a laugh at my expense. Like many of you, I participate in more than one project. For me it's this one, Prime Grid, and Einstein. My Nvidia GPUs are running PG and my AMD cards are here. I hit up Einstein when this project went through that rough spot the last couple days. Now this all relates to the thread I promise. I noticed that Einstein seemed to be slow to give me work as well, but there is chatter over there about WUs that allowed me to believe it could be me. Now this project is back to normal and as I said I was getting few WUs while others have said they getting work no prob. So i got to thinking "gee Hold, what would cause all your projects to get limited work?" I strolled over to PG to see if I found any primes being Tour de Prime and all and it hit me. You idiot, you set your WU que to 0 days. So ever hopeful, I set up an alternate venue that allowed several days que and ploped my primary MW cruncher in that venue. Told MW to get work and POW...900 WUs. Sorry if I cause you any worry Tom, looks like all is actually well with the servers, I'm just a scrub. Ok, y'all can stop laughing now lol.

You will find running the same project on your cpu and gpu will cause problems too as they do not have separate caches.

Milkyway@Home: Notice from BOINC
Your current settings do not allow tasks from this project. To fix this, you can change Project Preferences on the project's web site.
Tue 17 Jul 2018 12:14:47 AM PDT

Frequency (in Hz) that should try to complete individual work chunks. Higher numbers may run slower but will provide a more responsive system. Lower may be faster but more laggy. 
default 60 (corresponds to 60 fps)