Hello,
this is not weird, this is how the Internet works.
Customers and Peers are always treated differently. Let me explain it to you:
> confirm that "accept" is correct from "Learned from Customer" in ebgp-in to "ebgp-out to customer"
If you have two downstream customers connected, you want to achieve that customer A can reach customer B's prefixes directly through your own ASN. You don't want that Customer A's traffic flows to your paid IP upstreams to route it through half of the Internet to gain lots of ms RTT and then back to Customer B. The shortest possible path is always the best (with some exceptions, mostly financial ones)
> If this is correct, why there is a "reject" from "Learned from Peer" in ebgp-in to "ebgp-out to peer"
Because most probably you won't have enough bandwidth available to act like an IXP. A second example:
The reason to have a peering is to get as much as traffic away from paid IP Upstreams (like Cogent, CenturyLink, NTT, ...), as peerings normally do not have a monthly/yearly fee. And to shorten the AS path of course, which means less RTT in most cases.
You have a private peering with Peer A and a private peering with Peer B. If you don't announce prefixes of Peer A to Peer B, then only your own AS and your downstream customers can take advantage of this, which is good, because they pay for this.
If you announce prefixes of Peer A to Peer B, then Peer A could send the whole traffic to Peer B through your ASN, and they don't pay for this. The whole traffic could be only 2 Mbps, but it could be 300 Gbps as well. I don't think that you want to provide such a huge bandwidth capacity to companies which do not have any contractual relationship to you, and therefore don't pay you anything at all.
HTH