What's the point of aggregate routes when the default preference is reject?

studying for my JNCIS-SP and finally digging into the minutiae. I’m trying to grasp the default behavior of aggregate/summary routes. Why are these a reject? Maybe I’m just using them wrong, but here’s my config:

vMX6

[edit]
jcluser@vMX6# show routing-options
static {
    route 0.0.0.0/0 next-hop 100.123.0.1;
}
aggregate {
    route 172.29.0.0/22;
}

[edit]
jcluser@vMX6# show policy-options
policy-statement aggregete->ospf {
    from protocol aggregate;
    then accept;
}

[edit]
jcluser@vMX6# show protocols ospf
area 0.0.0.2 {
    interface ge-0/0/3.0;
    interface ge-0/0/4.0;
    interface lo0.0;
    interface ge-0/0/1.0;
}
export aggregete->ospf;

[edit]
jcluser@vMX6# run show route 172.29.0.0/22

inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.29.0.0/22      *[Aggregate/130] 00:03:05
                       Reject
172.29.0.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.0.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0
172.29.1.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.1.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0
172.29.2.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.2.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0

[edit]
jcluser@vMX6#

vMX1

jcluser@vMX1> show route 172.29.0.0

inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.29.0.0/22      *[OSPF/150] 00:00:41, metric 0, tag 0
                    >  to 10.100.12.2 via ge-0/0/0.0
                       to 10.100.14.2 via ge-0/0/1.0

jcluser@vMX1> ping 172.29.0.1
PING 172.29.0.1 (172.29.0.1): 56 data bytes
^C
--- 172.29.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

jcluser@vMX1> ping 172.29.0.1
PING 172.29.0.1 (172.29.0.1): 56 data bytes
36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f16b   0 0000  3f  01 c7ba 10.100.12.1  172.29.0.1

36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f194   0 0000  3f  01 c791 10.100.12.1  172.29.0.1

36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f1bf   0 0000  3f  01 c766 10.100.12.1  172.29.0.1

^C
--- 172.29.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

jcluser@vMX1>

My intention was to drop the entire /22 into the table and have the smaller subnets (the three /32s really) reachable and have everything else rejected, however in doing that I would have to build my /24s on an OSPF interface so that the smaller subnet routes are exported as well. I’m curious as to why this is? I’m attempting to introduce an LSA that advertises an external route, but without the smaller routes. I thought about writing an export policy that rejected the range smaller than /23, but I didn’t get a chance to get too far down that rabbit hole, and the end goal as I see it would still be the same, a route to a subnet that for all intents and purposes is unreachable.

Besides advertising a blackhole into a routing table, what’s the purpose of all of this? Why would I want to provide a summary if it’s never going to be reachable without the smaller routes? How does this decrease the size of the other routers? Obviously I’m missing something here, but I’m not seeing it.

edit
I’m confused as to why the question and the first answer (which answers most of my question) were down-voted. Normally on other SE sites I see mods making changes to clarify the question instead of simply down-voting it. Is there a better question I could be asking?