Python 2.6 has been EOL since 2013.
The Python 2.6 build is currently broken, and I've not the motivation to fix it.
In the past 30 days, there's been only 1--exactly 1--non-Linux download of marshmallow 2 on Python 2.6.

I think it's past time we drop official Python 2.6 support in marshmallow 2. We don't need to change the code--just stop testing against it.
Moving forward, I think we should keep the policy of dropping Python versions iff they are past their EOL date and have low usage (this will be a judgment call).
Any objections, @lafrech @deckar01 ?
Here's the pip installs for all marshmallow versions from PyPI for June 2019, showing very low numbers for 2.6:
| category | percent | downloads |
|----------|--------:|----------:|
| 3.6 | 35.79% | 398,246 |
| 2.7 | 34.81% | 387,385 |
| 3.7 | 21.40% | 238,157 |
| 3.5 | 6.28% | 69,934 |
| 3.4 | 0.97% | 10,846 |
| null | 0.69% | 7,708 |
| 2.6 | 0.02% | 241 |
| 3.8 | 0.02% | 193 |
| 3.3 | 0.00% | 10 |
| 3.9 | 0.00% | 1 |
| Total | | 1,112,721 |
Source: pypistats python_minor marshmallow --last-month # pip install pypistats
Yeah, the vast majority of the 2.6 installs are probably CI builds, which is why I counted non-Linux downloads in my OP.
This project is maintained by volunteers. Someone willing to run an unmaintained Python version, especially one that has been unmaintained for years, either doesn't mind unmaintained stuff and won't update his marshmallow version, or spends a lot of money or time maintaining Python and other libs and he can add marshmallow to the list. There's no point carrying that burden ourselves.
Moving forward, I think we should keep the policy of dropping Python versions iff they are past their EOL date and have low usage (this will be a judgment call).
This.
(Besides, this policy allows us to keep PY3.5 in MA3 for now with an open door to drop it when it's EOLed without waiting for MA4. We could make it clear right away in the docs or changelog. Is there a known good practice / convention about this?)
A cursory review of other mature projects shows that the above policy is common. I agree it would be good to document somewhere. Will do that when I have some extra time.
I put together a little dashboard that should help with these decisions in the future: https://marshmallow.sloria.io/
Most helpful comment
I put together a little dashboard that should help with these decisions in the future: https://marshmallow.sloria.io/