没啥不行啊，在一些场景下可读性更好是肯定的，我觉得就是三点不方便，
一个是输入效率，大部分编辑环境对于拼音补全支持得不好，ascii 字符基本输入两三个就可以选到自己想要的了，
第二就是你这段代码其主要是数据定义，又比较好对齐，所以比较好看，可以放到更加复杂的逻辑（比如几层嵌套）中，看着其实会更混乱一些。
第三是没办法避免中英文混杂的问题，比如图中的“payment proportion” 和”in fact contact money last time”为啥不用中文呢，要么就是这是其他库的变量，要么这是团队其他人写的或者遗留代码，这是没法完全避免的。那你们的规范到底是什么时候用中文，什么时候用英文呢。
我对于任何编码规范的看法是，只要团队内成员能一致同意并且遵守，就没啥问题，比如你定大括号必须换行 /一行内的语句可以不用换行，缩进用 4 格还是 2 格，都会有人喜欢或者不喜欢，因为程序员审美观不同。上面说的后两点其实都是审美观问题，只要团队成员能接受并遵守一致的约定，那就没问题。
如果要解决第三个问题，可以给团队定一个专有词汇表（注释或者集中写一个
glossary.md ），项目内这些专有名词必须用这些文本表达。实际上我即使在纯英文的项目里都会这么干，一些容易引起混淆的词或者常用的缩写我会写在这里。比如我写一个图像处理程序，图像中间会经过各种变换，我可以定义，要求一开始输入的图像数据统一称为 input （而不是 raw, original, 原始图像, etc.），这样项目里 所有 input_前缀的都是代表输入的原始数据(input_dimension, input_height, input_file ），不会引起混淆。如果没有这类规范，可能就会在一个地方看到 raw_height, 另一个地方看到“输入图像高度”, input_rows ...
例如楼主的项目里肯定要约定，”实付工程款”这类概念(明显不止一个变量，在整个项目中会到处定义这类变量)，在能控制的代码里，必须统一用这五个中文字符，不允许用 payment 之类的代替，否则可能会引起混淆的，至少是可读性上的不便，因为看到 payment 和实付工程款同时出现的时候，我需要反应一下这是不是同一个概念（如果有的地方相同，有的地方不一样，那就很恶心了）
开源项目要面向全世界的话，那唯一能让大部分程序员都接受的规范也就是英文变量了
pep 8:
For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131): All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST provide a transliteration of their names in this character set.
Open source projects with a global audience are encouraged to adopt a similar policy.