The Robert Martin approach targets readability. To fully enjoy the benefits you have to apply additional conventions or rules (e.g., naming, abandon comments for the sake of choosing meaningful and descriptive names, single responsibility, short methods, ...). Then you can read your code like a common text document. If indenting the next abstraction level function block enhances readability as well. This way you can express abstraction levels by your code format:
public void Level1Member()
{
RunLevel2Member();
RunAnotherLevel2Member();
}
private void RunLevel2Member()
{
RunLevel3Member();
}
private void RunLevel3Member()
{
//....
}
private void RunAnotherLevel2Member()
{
//..
}
Maybe you'll find yourself abusing your mousewheel when using the alphabetical style just to scroll up and down to get your context. On the other hand you don't need to maintain any indentions and abstraction levels when refactoring your code.
This are two different approaches having different targets. One likes to enhance readability (for humans) and lets you find methods by the program flow while the other likes you to find methods fast by their name. Alphabetical sorting supports the common convention to place all public methods together which also increases the chance to figure out the purpose and behaviour of a class (at a glance). Step-down happily mixes public and private methods following a different aim.
You can't have both. So under no circumstances violate hundreds of rules and omit refactoring just to mix up this two styles. Makes no sense and makes the code much less readable.
If you think reading the step-down style feels more comfortable and natural than reading code in a dictionary style you should use it. I do.
Never heard of Microsoft internal conventions like sorting their code alphabetically. The official .NET convention doesn't target an organisation or convention for the structure of code (beside e.g. recommending to place event delegate at the top of a class, etc.).
Step-down rule is just an unofficial style. Some auto-formatting tools don't support indenting methods and places them back on one level.
By the way, using partial classes to obscure bad design (too big classes/ too much responsibility) is not an option for somebody caring about clean and maintainable code.
To make things easier for yourself I would try to show your team the advantage of your style or accept the style the majority of your team prefers.
Don't forget that your IDE assists you very well by highlighting the methods in your code or providing features like 'go to implementation' or 'find usages' or code maps showing the order of method calls. And there are rules of much more importance regarding code readability like good names and good design. But I personally prefer step-down.